This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: reject merges on gdb release branches?

On Fri, Jan 24, 2014 at 6:27 AM, Eli Zaretskii <> wrote:
> [Resending because the list rejected the attachment.]
>> Date: Fri, 24 Jan 2014 15:55:48 +0400
>> From: Joel Brobecker <>
>> Cc:,,
>> > 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]