corrected ascii-art; Re: Disable backing out merges?

[Matt Mackall]

[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.