Disable backing out merges?

Dominik Psenner dpsenner at gmail.com
Mon Oct 10 02:03:09 CDT 2011

>-----Original Message-----
>From: mercurial-devel-bounces at selenic.com [mailto:mercurial-devel-
>bounces at selenic.com] On Behalf Of Matt Mackall
>Sent: Saturday, October 08, 2011 7:46 PM
>To: Arne Babenhauserheide
>Cc: mercurial-devel at selenic.com
>Subject: Re: Disable backing out merges?
>On Sat, 2011-10-08 at 15:19 +0200, Arne Babenhauserheide wrote:
>> Am Donnerstag, 6. Oktober 2011, 16:03:48 schrieb Matt Mackall:
>> > On Thu, 2011-10-06 at 22:45 +0200, Arne Babenhauserheide wrote:
>> > > The only way to get rid of them after subsequent pushed commits are
>> > > clean
>> > > backouts.
>> >
>> > ..except we know this doesn't actually work for merges and causes lots
>> > of pain.
>> .
>> > > Or fix the backout logic?
>> > I have no idea how to do that, and I actually suspect that a
>> > satisfactory answer doesn't exist. If you know better, I'm ready to be
>> > impressed.
>> Essentially the problem is, that a merge is a special operation which
>> later merges, right? A backout then only undoes the content changes, but
>> the graph changes.
>> a-b-c-x ? broken
>>  \   /
>>    d
>> A backout of c would need to make x a valid changeset,
>I lost you right here. There are two completely different cases I'm
>interested in:
>a) merge should not have been done at all (ie merged default into
>b) merge was done incorrectly (ie accidentally dropped changes)

I would distinguish in both cases whether the merge has produced some
valuable stuff or not.

A) If it does not include any valuable changes, it would not make sense to
keep the history of the bad merge and therefore I would strip the merge
changeset and ban it to produce a dag like:

a-b-c-e      a-b-e'
 \ /     =>   \
  d            d

Unfortunately this is not possible without modifying the hash of e, thus
producing e'. To make sure the bad changesets don't flow back into the
repository, I would have to ban the changesets c and e (and therefore also
all descendants of e).

B) If it does contribute any valuable changes and I wanted to keep it for
historical reasons, I would have to re-do the merge, mark the bad one and
rebase all new changesets e on the new merge head. Since e was changed into
e', I would have to ban changeset e (and therefore also all descendants of

                 /    /
a-b-c-e       a-b-c! /
 \ /      =>   \ /  /
  d             d---

Unfortunately I would be unable to prevent anyone from pushing descendants
of c and therefore one could easily push bad changesets based upon the
broken c.


More information about the Mercurial-devel mailing list