Re: fast-forward only policy

[Felipe Contreras <felipe contreras gmail com>]

On Tue, May 5, 2009 at 12:07 AM, Marc-André Lureau
<marcandre lureau gmail com> wrote:
> Hi
>
> On Mon, May 4, 2009 at 11:38 PM, Zeeshan Ali (Khattak) <zeenix gmail com> 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