Re: reject merges on gdb release branches?

[Ricard Wanderlof <ricard.wanderlof@axis.com>]

On Thu, 23 Jan 2014, Eli Zaretskii wrote:

>>
>> I think it's not the merging per se that is a problem, only if it is done
>> incorrectly, i.e. merging from a branch that was was broken off from
>> master a long time ago, which brings in a lot of unwanted stuff.
>
> There's any number of ways one can make a mistake and screw up master.
> That cannot be the reason for forcing a particular workflow on
> everyone, certainly not before any such problems actually happened
> even once.
>
> And I don't understand your fear of unwanted stuff from a divergent
> branch: what exactly is special about this situation?  Surely,
> examining the diffs before committing and pushing would show what is
> about to land on master, so where's the danger that doesn't exist in
> any other commit?

I'm not trying to advocate one or the other, rather just trying to 
understand the reasoning behind the decision.

Personally I always check what I've got locally with gitk or other tool 
which provides an overview of what I'm about to push before I do it. I 
agree that there are more than one way to screw up a master, still, it 
would be prudent to gain from the experience of other similar projects 
even though nothing bad has happened with gdb yet (very likely owing to 
the fact that gdb has only been using git for a couple of months).

> Again, I can understand that some people are accustomed to rebasing,
> and I'm okay with that.  But I don't understand why something that is
> essentially a matter of personal preferences is forced on everyone.
>

/Ricard
-- 
Ricard Wolf Wanderlöf                           ricardw(at)axis.com
Axis Communications AB, Lund, Sweden            www.axis.com
Phone +46 46 272 2016                           Fax +46 46 13 61 30