Mercurial Undo Merge

Question

Have a scenario where we un-intentionally merged a named branch (ABC) into our default branch.

hg rollback is not an option beca

Answer 1

If you haven't publish the repo publicly you can do this

hg clone -r (parent1 of bad merge) -r (parent2 of bad merge) old new

and delete the old repo.

Answer 2

I came across the following scenario today:

@    changeset:   1728:5d703e1051d3
|\   parent:      1727:1a5f73b5edb4
| |  parent:      1720:65ffffd0bde225
| |  user:        nn
| |  date:        Wed Feb 27 10:35:00 2013 +0100
| |  summary:     Merge with SomeBranch
| |
| o  changeset:   1727:1a5f73b5edb4
| |  user:        nn
| |  date:        Wed Feb 27 10:34:30 2013 +0100
| |  summary:     lorem ipsum
| |
[some more changesets]
| |
o |  changeset:   1720:65ffffd0bde225
| |  branch:      SomeBranch
| |  user:        nn
| |  date:        Wed Feb 27 07:44:46 2013 +0100
| |  summary:     lorem ipsum

Where SomeBranch should not have been merged into default. What we did to solve this, was to use the backout command with the parent option like so:

hg backout --rev=1728 --parent=1727

By this you don't undo the merge itself: Looking at a branch graph (either with graph log or in TortoiseHg) you'll still see SomeBranch going into default at r1728. The result of the merge is however undone, meaning that the changeset containing the backout (r1729 in my case) is identical to r1727.

Answer 3

You're going to need the Mq extension. If you don't have it turned on, do so by adding this to your Mercurial.ini or .hgrc file.

[extensions]
hgext.mq=

If you're not familiar with it, the Mq extension let's you manipulate history. The good news is, this will allow us to fix your repo. The bad news is that anyone who has a clone of the messed up repo will have to clone it again, because we'll be changing history.

First, go make another clone of your repo to work in, so we don't mess anything up.

Now, find the revision id of the merge changeset (that merged default and your named branch). Write it down. We'll refer to it as changesetM. Now find the revision id of the next changeset. Write it down. We'll refer to it as changesetN.

Once you have those two revision ids, head over to your command prompt and cd into your repo. Then type out the following, replacing changeset[M|N] with the appropriate revision id.:

$ hg qimport -r changesetN:tip
  # This will add all of your changes since the merge to the queue
$ hg qpop -a
  # This pops them all out of your history.
$ hg strip changesetM
  # This removes the merge changeset.
$ hg update -C default
  # Make sure we're on the default branch
$ hg qpush -a
  # Take the changesets in the queue and push them back onto your history.
$ hg qfinish -a
  # Remove changesets from the queue and finalize them as normal changesets.

Essentially, you are rebasing the new changesets on top of the default branch, removing the merge changeset in the process. Once you're done, you'll need to push the changes to a new repository on the server, and have your colleagues clone fresh copies.

Lastly, if you have any other Mercurial questions, also check out kiln.stackexchange.com.

UPDATE

I forgot to mention: If someone has based changes on something that was only in the other branch, it is possible that hg qpush -a will fail. You'll see a foo.txt.rej and foo.txt.orig file laying around. Unfortunately, you'll have to fix this yourself. To fix it, open the original file, the .orig file, and the .rej file and choose the right changes to merge in, saving them in the original file. Once you've merged it in, use hg qrefresh to update that patch to the new, merged patch. From their, you should be able to run hg qpush -a again and continue. If you run into the same error again on another patch, just follow the same process.

Answer 4

"Mercurial: The Definitive Guide, Chapter 9. Finding and fixing mistakes, Dealing with committed changes"