On Saturday 19,June,2010 11:22 PM, Frank Lanitz wrote:
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.
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.