corrected ascii-art; Re: Disable backing out merges?
mpm at selenic.com
Tue Oct 11 02:30:58 CDT 2011
[thanks, these pictures make sense here]
On Tue, 2011-10-11 at 08:12 +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 affects
> later merges, right? A backout then only undoes the content changes, but not
> the graph changes.
> a-b-c-x ← broken
> \ /
> A backout of c would need to make x a valid changeset, so it would actually
> have to
> (a) rebase x on b or d und then close c-x, or cleaner but more complex
> (b) do a new merge of d and b, rebase x on it and then merge x with that,
> discarding the changes from x.
> a-b-c-x † ← closed
> \ /
> d-x' ← OK
> \ \ c'-x'-y ← OK
> \ X /
> \ / c---x ← broken
> y = x - c + c'
> So essentially y is a rebase of x on c', followed by a dummy merge of x on x'
> to replicate the graph change.
> If I did not miss something, future merges should then work without problems.
> So actually a backout of a merge is either
> (a) a rebase + close (there should never have been a merge in the first place),
> (b) a remerge + rebase + dummy merge (merging was the right thing to do, but
> the exact merge was bad).
> (a) and (b) should warn everyone who wants to push ancestors of the bad merge,
> because they would introduce a new non-closed head.
> Is this correct?
I don't think so. If during this process, other people have done work
based on c and merge their work in, I think it's still likely to have
things go wrong.
Again, it comes back to creating a future ambiguous merge ancestor.
Introducing c' doesn't take c out of the graph, which means it may still
end up being the basis for a future merge, thus reproducing the bad
Closing heads or branches doesn't help - you should assume that the
merge mistake isn't typically discovered until it's been pushed, pulled,
and merged into other people's repos long before someone notices their
work has vanished.
Mathematics is the supreme nostalgia of our time.
More information about the Mercurial-devel