[Geany-devel] Git switch
Chow Loong Jin
hyperair at xxxxx
Sat Jun 19 16:22:14 UTC 2010
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.
>> 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.
>> 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.
Chow Loong Jin
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 262 bytes
Desc: OpenPGP digital signature
More information about the Devel