corrected ascii-art; Re: Disable backing out merges?
Matt Mackall
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
> \ /
> d
>
> 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)
>
> a-b-c-x † ← closed
> \ /
> d-x' ← OK
>
> (b)
>
> a-b-\
> \ \ c'-x'-y ← OK
> \ X /
> \ / c---x ← broken
> d-/
>
> 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),
> or
> (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
changes.
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
mailing list