Disable backing out merges?

Angel Ezquerra angel.ezquerra at gmail.com
Thu Oct 6 16:51:21 CDT 2011

On Thu, Oct 6, 2011 at 11:03 PM, Matt Mackall <mpm at selenic.com> wrote:
> On Thu, 2011-10-06 at 22:51 +0200, Angel Ezquerra wrote:
>> On Thu, Oct 6, 2011 at 9:45 PM, Matt Mackall <mpm at selenic.com> wrote:
>> > Seems a bunch of people are trying to use backout to deal with broken
>> > merges. That doesn't work:
>> >
>> > - it's not well-defined what the result should be
>> > - we can't actually erase the problematic DAG edge
>> >
>> > So it seems like we should just refuse to do it until we get a lot
>> > smarter here.
>> Say I have made a merge and pushed it. Later I realize that it is a
>> bad merge and I want to get rid of it.
>> If it is not possible to back it out. What are the alternatives?
> If your problem is that "I did a merge when I shouldn't have" or "I
> should never merge branch X and Y and I did it anyway", backout doesn't
> really help you with your biggest problem: you've introduced a merge
> into the history graph that shouldn't be there. This bogus piece of the
> graph will confuse future merges and the only way to truly fix it is to
> destructively strip the bad merge from history and all clones. Backout
> can't help you at all here, nor can anything else.
> On the other hand, if you've incorrectly performed an otherwise
> reasonable merge, backout is still completely the wrong tool for the
> job. Backout undoes all the changes in a changeset, which is not what's
> wanted with a valid merge.
> So backout on a merge is ALWAYS the wrong thing.

Let's say that I don't really mind having the wrong merge on my
history, as long as nobody bases their work on it. What is the best
strategy in that case?

My first instinct would have been to redo the merge. In order to "mark
it" as wrong I would then close the corresponding head. Would that be


P.S.- Perhaps this conversation should be moved to the regular
mercurial mailing list?

More information about the Mercurial-devel mailing list