Backing out a bad merge after incorrect use of Transplant

[Matt Mackall]

On Thu, 2013-01-03 at 01:17 -0800, ee7arh wrote:
> Hi,
> 
> We just had a nasty situation which we couldn't figure out how to resolve
> after using the Transplant command incorrectly.
> 
> We have 2 branches: default and integration.
> 
> A changeset was committed to default branch which needed to be transplanted
> onto integration branch. We could not merge the head of default to
> integration since there were other changesets behind which did not yet need
> to be on the integration branch, that is why we wanted to use the HG
> Transplant command.
> 
> When using the Transplant command (inside MercurialEclipse), we accidentally
> used the "merge" option and so the changeset was transplanted onto
> Integration branch successfully but was also recorded as a merge thus having
> 2 parents (the transplanted changeset from default branch and the last
> changeset from integration branch). In effect, Mercurial showed that a
> complete merge had been made from default to integration even though only
> the diffs of the Transplanted changeset went over.

FYI, not many of Mercurial's developers use Eclipse, let alone
MercurialEclipse. So when you describe things in terms of what
MercurialEclipse does, it doesn't mean much to us.

But it sounds like in the end, 'hg transplant --merge' got invoked.
Probably not what you wanted. I'm not sure what the purpose of --merge
was supposed to be and the docs don't tell us; most people use the graft
command introduced in 2.0 instead of the transplant extension these
days.

> This meant that when we later added changesets onto the Integration branch
> and attempted to merge those changesets back to default branch (part of our
> normal workflow), the net result was that Mercurial attempted to delete a
> lot of code (which had been committed earlier in the default branch). At
> this point we realised that we had messed up the Transplant command and
> should not have used the merge option.

So your graph looks like:

d-d-d-d-d-d-d-d-d-d-d-T-d-d-d-M <- default with transplant T
         \           /       /
          i-i-i-i-i-t-i-i-i-i   <- integration with fix t

(hopefully your email reader has a fixed-width font)

Here, definitionally, the merge at M will only consider changes on i
back to the common ancestor, t, because we've already merged at T.

> Since changes were pushed to a central repository, we attempted to do a
> Backout of that merge favouring the parent changeset on the default branch.

The problem here is that a backout cannot erase the edge from t to T.
Nothing can, in fact.

> Anybody an idea how to resolve such a situation without Stripping out the
> changesets completely? 

You need to force it.

By that, I mean do a merge, then manually overwrite the result of the
merge with the desired, correct result before committing.

Make sure all dangling branches are tied up and everyone is basing their
work on this forced merge going forward. Otherwise the problem may come
back!

Which leaves us with the problem of producing the desired result. What
not to do: try to coax the result out of Mercurial with merges. You've
already misinformed Mercurial about how to merge these branches and
there's no way to tell it to ignore the last merge.

Probably the most straightforward thing to do is:

- clone your repo to 'fixup'
- update to just before T
- do the transplant correctly (transplant with no -m or graft)

                      T'      <- correct transplant
                     /
d-d-d-d-d-d-d-d-d-d-d-T-d-d-d <- default
         \           /       
          i-i-i-i-i-t-i-i-i-i <- integration


- rebase the d changesets after T onto the new T'

                      T'-d-d-d  <- rebased development
                     /
d-d-d-d-d-d-d-d-d-d-d-T <- default
         \           /       
          i-i-i-i-i-t-i-i-i-i <- integration

- do a merge:

                      T'-d-d-d--Mgood  <- rebased development
                     /         /
d-d-d-d-d-d-d-d-d-d-d-T       /
         \           /       /
          i-i-i-i-i-t-i-i-i-i <- integration

This M is the desired result which ignores the t->T edge that was
causing problems.

- go back to your broken repo and do a merge, but don't commit yet
- copy the Mgood result out of fixup into your working directory
- inspect it for correctness
- commit with note 'merge integration, fixup for bad transplant'

-- 
Mathematics is the supreme nostalgia of our time.