Re: reject merges on gdb release branches?

["H.J. Lu" <hjl.tools@gmail.com>]

On Fri, Jan 24, 2014 at 6:27 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> [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?

I use both rebase and merge. I use merge on hjl/linux/master
branch since I need to go back to checkout previous trees on
my branch. Rebase won't work for me here.

But for hjl/mpx/pltext8 branch, I use rebase since I
plan to commit it to master when the work is complete
and I don't need to go back in history.

I don't care about the history of each commit on master
and release branches.  Merge will only confuse me.
But you can tag your merged commit before rebase or
create a branch for it.  All history will be there for you
and it won't confuse other people.


-- 
H.J.