reject merges on gdb release branches?

Eli Zaretskii eliz@gnu.org
Fri Jan 24 11:39:00 GMT 2014


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



More information about the Gdb-patches mailing list