On Saturday 19,June,2010 11:22 PM, Frank Lanitz wrote: > On Sun, 13 Jun 2010 23:59:11 +0800 > Chow Loong Jin <hyper...@gmail.com> wrote: > >> On Sun, 13 Jun 2010 13:11:43 +0200 >> Enrico Tröger <enrico.troe...@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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel