On Sun, 13 Jun 2010 23:59:11 +0800 Chow Loong Jin hyperair@gmail.com wrote:
On Sun, 13 Jun 2010 13:11:43 +0200 Enrico Tröger enrico.troeger@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:-
- Clone the git repository from sourceforge.net
- 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.
Thanks, Frank