views:

76

answers:

3

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

hg rollback is not an option because there have been a couple commits since.

Is there a way to undo this?

+1  A: 

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.

in3xes
This works... thanks! Now I have a remaining problem: how to get the changesets applied after the bad merge into my newly cloned repository?
Steve Horn
@Steve See my answer. You'll have to "rebase" them on the old head.
tghw
@in3xes backout can't undo a merge.
tghw
+1  A: 

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.

tghw
I'm with you until hg qpush -a. I get the following in the console:applying xxx.diffpatching file -----Hunk #1 FAILED at 8061 out of 1 hunks FAILED -- saving rejects "..."patch failed, unable to continue...errors during apply, please fix and refresh 310.diff
Steve Horn
See the updated section in my answer.
tghw
This destroys history, so it will not work if the mistake has been propagated. See: http://stackoverflow.com/questions/265944/backing-out-a-backwards-merge-on-mercurial
Jesse Glick