[Geany-devel] Git switch

[Chow Loong Jin]

On Saturday 19,June,2010 11:22 PM, Frank Lanitz wrote:
> On Sun, 13 Jun 2010 23:59:11 +0800
> Chow Loong Jin <hyperair at gmail.com> wrote:
> 
>> On Sun, 13 Jun 2010 13:11:43 +0200
>> Enrico Tröger <enrico.troeger at uvena.de> wrote:
>>
>>> On Sat, 12 Jun 2010 21:30:24 +0200, Jiří wrote:
>>>
>>>
>>>> This choice will also influence the workflow in which you will use
>>>> git. If contributors cannot have their branches hosted easily,
>>>> then the the Linus model (one pusher pulling from contributors)
>>>> will be harder to realize.
>>>
>>> I doubt we want that.
>>> Who should be "our Linus"?
>>> I can't do that and I guess Nick also not. And I also don't see any
>>> advantage for Geany with such a scenario.
>>>
>>> I'd rather keep the existing way of committing: a couple of people
>>> have write access to trunk (or then master). They commit their
>>> changes and patches and whatever.
>>>
>>>
>>> Regards,
>>> Enrico
>>>
>>
>> Then let's not go the Linus route. We can always adopt a working model
>> as follows, which I've attempted to translate from the svn workflow as
>> best as I can:
>>
>> We host Geany (git) on sourceforge.net. Developers who have push
>> access (i.e. the ones who currently have commit access to svn) can
>> push new commits there.
>>
>> Contributors:-
>> 1. Clone the git repository from sourceforge.net
>> 2. Do their work locally, and produce commits of the fixes/new
>> features they implement.
>> 3. They then submit these back to you via:
>>    * Mailing list: git format-patch can generate patches formatted
>>      properly for this purpose.
>>    * Remotely hosted branches: gitorious.org/github.com can be very
>>      useful for these, no matter how much you hate them. It'd be worth
>>      having a mirror of Geany on gitorious.org/github.com to allow for
>>      users to perform remote-cloning and pushing of new commits, so
>>      that you can either rebase or merge these back into the main tree
>>      hosted at sourceforge.net.
> 
> This is correct, but I don't see any advantage of using git/bzr,
> mercural, bitkeeper or whatever in favor of subversion of doing this.

Point #2 isn't really feasible with svn, for more than one patch at a time. And
then these patches can get outdated and fail to apply, requiring the person who
wrote the patch to keep maintaining it until the patch is committed.

git format-patch is the solution to the aforementioned problems, since it can
generate a series of patches, each with a suitable commit message, from a series
of commits since the patches have some hashes included within them so that git
can fall back on a 3-way merge when applying these patches if all else fails.

Of course, git format-patch can be done with geany still using git-svn, but how
many developers do you want to see using git-svn before switching from svn to
git? I think most of us already do, in geany's case. Hence, this discussion.

-- 
Kind regards,
Chow Loong Jin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://lists.geany.org/pipermail/devel/attachments/20100620/0fcb8049/attachment.pgp>