On Tue, May 5, 2009 at 12:07 AM, Marc-André Lureau <[email protected]> wrote: > Hi > > On Mon, May 4, 2009 at 11:38 PM, Zeeshan Ali (Khattak) <[email protected]> > wrote: >> Hi, >> I was one of the happiest person on this planet the day we moved to >> git and i can't thanks the people involved enough. Although overall i >> am pretty happy with the migration, I do have one concern: The policy >> of disallowing non-fastforward pushes to any branch. I understand that >> this is good for master and other stable branches, but otoh I think it >> breaks the usual git workflow for feature branches. >> >> I had a little chat with Owen regarding this: >> >> == IRC LOG BEGIN== >> <zeenix> owen: hi, are we sure about this 'only fastforward for all >> branches' policy? >> <owen> zeenix: Well, if we had a way of figuring out that some >> branches where feature branches not maintenance branches, then we >> could conceivablly allow rebasing those branches >> zeenix: But not sure how to do that. I suppose we could say if there >> are no numbers in the branch name it's a feature branch, but that >> would make thigns weird if you had a branch 'bonobo-removal-2' or >> something >> <zeenix> owen: or you could make developer put some specific prefix in >> the name of feature branches? >> <owen> would be a bit ugly if all our branches were named feature-* >> <owen> zeenix: feel free to mail suggestions for a policy to >> gnome-infrastructure >> <zeenix> ok, will do >> ==IRC LOG END== >> >> I am sending this mail here cause I thought it might be better to >> have a discussion on this and so that other developers can speak-up if >> they (dis)agree. >> > > > Since we are supposed to have "[project]-[MAJOR]-[MINOR]" for stable > branches (see http://live.gnome.org/Git/Developers), what about > limiting policy to those + "master" ? > > (also, deleting the feature branches should be possible)
Yes, a way to differentiate fixed to moving branches like that would be sensible, but what is the point of having 'project' in the branch name? Branches are per-repository, so you would never have a non 'gtk-' branch in the GTK+ repo. In fact, AFAIK at any given time GNOME projects have at most two lines of development. When GTK+ 2.17 is released, work on 2.16 is continued, but not on 2.15, so what is the point of keeping the 'gtk-2-15' branch? (or gtk-2-14) In reality you only have a 'master' and a sometimes a 'devel' branch. I would suggest a few official branch names like 'master' and 'devel', and a special two character prefix for personal branches like 'za-transcoding-rework' (Zeeshan Ali's personal branch), the rest would be up to the project to decide. Remember that in git, branches are just pointers (which usually increment automatically); it's very easy to create, rename, delete, and update the destination. Cheers. -- Felipe Contreras _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
