Re: reject merges on gdb release branches?

[Eli Zaretskii <eliz@gnu.org>]

[Resending because the list rejected the attachment.]

> Date: Fri, 24 Jan 2014 15:55:48 +0400
> From: Joel Brobecker <brobecker@adacore.com>
> Cc: will.newton@linaro.org, ricard.wanderlof@axis.com,	gdb-patches@sourceware.org
> 
> > I'm not talking about review: for review we send and receive diffs,
> > not commits with their metadata.  I'm talking about the history DAG
> > after the commit and the push.  And, as you well know, a merge that
> > causes conflicts requires a commit after resolving those conflicts.
> 
> I don't understand what you mean, anymore.

Sorry about that.  What I meant to say was that the merge vs rebase
issue is not relevant to patch review.

> > > Sure. Attached is a gittk screenshot.
> > 
> > And what exactly are the difficulties with that?
> 
> I can guaranty you that most people will find this non-linear history
> at best hard to follow, at worst plain confusing. I consider myself
> relatively well versed in git, and yet I consider this type of history
> to be fairly hard to follow. While you do not seem to have trouble
> with it, you have to think about the others.

In Emacs development, we don't have any trouble with even more
complicated DAG structures.  See the attached for a (relatively
simple) example.

> We'll have to agree to disagree, then (and I use merges routinely,
> so I think I also have a good handle on them). The problem I have
> with your request is that we're trading a one-off operation (merge
> vs rebase) against a history that is necessarily more complicated.
> And most, if not all people who expressed an opinion, confirmed that.

Why does this issue have to be decided by a majority?