Disable backing out merges?

Angel Ezquerra angel.ezquerra at gmail.com
Thu Oct 6 17:15:55 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.
>> I could redo the merge, but then wouldn't that create a new head when
>> I push it? Perhaps I would need to also perform a dummy merge between
>> the old, bad merge, and the new, good one? Or maybe I could close the
>> merge branch? Would that work?
> I don't think that's correct for either use case.

Let me be a bit more specific about what I meant. I attach to this
email 3 pictures showing what I think I would try to do if a bad merge
had been pushed.

- Step 1: create a new, valid merge.
- Step 2: Close the bad merge branch. Use the commit message to
explain that the merge parent should not be used.

Here I would like to be able to push but mercurial would refuse since
it would create new heads. But since one of the heads is "closed" it
seems that there would be no harm in pushing that "dead" branch, would

- Step 3: To be able to push all of these, I could merge the closed
branch into the good merge revision. Before committing the merge I
would revert all files to the valid merge revision.

I admit that this is a convoluted procedure. But is it a valid one?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: step1.png
Type: image/png
Size: 8021 bytes
Desc: not available
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20111007/b2657676/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: step2.png
Type: image/png
Size: 8929 bytes
Desc: not available
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20111007/b2657676/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: step3.png
Type: image/png
Size: 11278 bytes
Desc: not available
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20111007/b2657676/attachment-0002.png>

More information about the Mercurial-devel mailing list