Am 19.06.2010 18:22, schrieb 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 Jinhyperair@gmail.com wrote:
On Sun, 13 Jun 2010 13:11:43 +0200 Enrico Trögerenrico.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.
The main flaw of SVN IMO. It basically forces you to have multiple checkouts, each having the double size of the source code.
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.
Yes, that's the point. Many of us mess with git-svn (an additional hurdle) while we could simply switch to git and make it easier for most people.
Best regards.