Re: reject merges on gdb release branches?

Eli Zaretskii
2014-01-24T11:39:16Z

> Date: Fri, 24 Jan 2014 15:30:14 +0400
> From: Joel Brobecker <brobecker@adacore.com>
> Cc: will.newton@linaro.org, ricard.wanderlof@axis.com,
> gdb-patches@sourceware.org
>
> > > If there are conflicts between your branch and the master branch,
> > > and those conflicts are not trivial to resolve, the commits needs
> > > to be reviewed again.
> >
> > Of course. I'm talking about the situation after they are resolved
> > and the result is committed.
>
> So, concretely, you would also send the merge commit as an extra commit
> for review?

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.

> > > > 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.
> > >
> > > But this is at the cost of everyone else finding it more difficult
> > > afterwards each time they consult the history.
> >
> > What difficulty are you talking about? Can you demonstrate on a real
> > history log that difficulty?
>
> Sure. Attached is a gittk screenshot.

And what exactly are the difficulties with that?

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