Re: reject merges on gdb release branches?

[Joel Brobecker <brobecker at adacore dot com>]

> 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.

> > 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.

> > I'll have to say that this discussion did reinforce my feeling that
> > the current rule has more benefits than drawbacks.
> 
> Sure, since benefits are yours, while drawbacks are mine ;-)
> 
> I'm asking to free me from the tyranny of this rule.  You are free to
> apply it in your work, but I still see no reasons to force me.  You
> are used to rebase, so you think a DAG with merges is somehow more
> complicated; it isn't.

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.

I apologize in advance, but I have to disengage from this discussion.
I think I've exposed my arguments, and have nothing else to add.
As I said, I will live with the outcome, whatever it is.

-- 
Joel