Re: reject merges on gdb release branches?

[Eli Zaretskii <eliz@gnu.org>]

> Date: Fri, 24 Jan 2014 10:35:24 +0000
> From: Will Newton <will.newton@linaro.org>
> Cc: Joel Brobecker <brobecker@adacore.com>, ricard.wanderlof@axis.com, 	"gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
> 
> >> The problem with merge commits is they make the history noisy. If I
> >> have a long running development branch I could have lots of:
> >>
> >> Merge branch 'master'
> >
> > That's easy enough to skip, if you aren't interested (I am).  I don't
> > see any real problem here, any development history has some amount of
> > noise if you are looking for certain things and aren't interested in
> > others.
> 
> That's fine if you have one or two, but in the degenerate case you may
> have half your commit history being merges. It's simply not helpful to
> anyone.

It is helpful to anyone who wishes to understand the sequence of
events that led to a certain line being what it is.  Merges are in
important part of that.  E.g., suppose that a merge produced a
conflict whose resolution mistakenly introduced a bug.  If you
eliminate the merge, you will be unable to understand the reasons for
the buggy change, at least not easily.

> >> Commits that don't serve any function. Yes, they mark that I merged
> >> master at that point, but if the changes do not interact with mine
> >> that is irrelevant
> >
> > In many, if not most, cases you will not know if they interact or
> > don't.  Once you've rewritten that part of history, it is lost
> > forever, even if you later need it.
> 
> The history is not lost, the history is all present. Essentially you
> have done the merge yourself (as part of the rebase) and squashed the
> merge into the functional commit.

Yes, and the information in the squashed part is lost.

Anyway, we are going in circles.  I'm not trying to convince you to
change your workflow, I'm asking to allow me to keep mine.