Re: reject merges on gdb release branches?

[Eli Zaretskii <eliz@gnu.org>]

> Date: Thu, 23 Jan 2014 08:46:32 +0100
> From: Ricard Wanderlof <ricard.wanderlof@axis.com>
> CC: Joel Brobecker <brobecker@adacore.com>, "gdb-patches@sourceware.org"
> 	<gdb-patches@sourceware.org>
> 
> 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?

> Loosing information about merges from master during a rebase I don't think 
> is too much of an issue. Once the branch has been rebased to master, any 
> merges from master would have occurred in the past anyway.

The information lost can be important when bisecting later, or more
generally researching how a given piece of code or bug entered the
code base.  It can also be important if I merge between my local
branches as part of working on a feature, something that isn't unheard
of.

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.