[Geany-devel] Git switch

[Chow Loong Jin]

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.
> 
> 
> 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.

Access control, directly translated from svn:
* Anyone who can commit to svn can push to git.
* Anyone who can commit to svn can create and modify branches in svn, so
  let anyone who can push to git create and commit to branches.

For purposes of migration to git, I think we can just adopt the model
I've proposed above first, and think about any other changes to further
reap any benefits git can bring later on.

-- 
Kind regards,
Chow Loong Jin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.geany.org/pipermail/devel/attachments/20100613/045712b1/attachment.pgp>