Mercurial branched revision history, two remote heads when pushing

Question

I committed a bunch of changesets locally (23-28) and then I realized that I wanted to go back to revision 25, so I ran "hg up -r 25" to go back. Then I started working from there and committed a few changesets. Now I'm ready to push my changes to the server, but when I try to do that it complains with "abort: push creates new remote heads on branch 'default'!". I thought someone else may have committed to the repository so I did a hg pull, but did not get any changes.

Here is the revision tree that I am working with

 23
 |
 24
 |
 25
 / \
26 29 
|   |
27 30
|   |
28 31
    |
   32
    |
   33
    |
   34
    |
   35

Is it possible to remove revisions 26,27, and 28? How can I fix things so that I can run "hg push" without errors? Should I have used a different command to go back to revision 25?

Answer 1

Well, there's two ways I know of.

Note: Please make a backup, or a clone to experiment on, I do not take responsibility for any lost work

First, if you got MQ extension enabled, you can strip those off. I only know how to do that using TortoiseHg, but I'll find the right commands after posting here.

To do this, you would execute this command:

hg strip 26

---

Secondly, you can create a new clone locally of only some of the changesets, again I only know how to do that using TortoiseHg.

To do this, you would execute this command:

hg clone SOURCEDIRECTORY CLONEDIRECTORY -r35

Then, from your clone, after verifying that it contains the changesets you want, you push against the target repository.

---

As for answering what you should've done instead, you could've deleted your original clone and re-cloned from the server to get a clean clone only containing up to changeset 25, but of course you could use the strip command to get rid of the excess changesets then as well.

Answer 2

Let me just throw in a voice of dissent on Lasse's answer. Mercurial is a system about building an immutable history. Think of a scientist working in his or her lab book on numbered pages in pen. Everything is important, even the stuff you wish you didn't write and don't want at this second. The strip command isn't enabled by default for a reason -- it violates the immutability that is a mercurial goal.

The more "Mercurial" way to address this would be to merge 26 into 35, selecting entirely the options from 35, so you're back down to one head. Then your push will still have only one head, but all of history is preserved.

Alternately you had the option to 'hg push -r 35' which would have given you no warning or error nor required -f because you'd be leaving the repo repo with only one head.

There's nothing wrong with strip, but it's not part of the traditional toolset or mindset in Mercurial.

Answer 3

There's nothing inherently wrong with having multiple heads - Mercurial is just checking it's what you want. In this case, you might want to keep the abandoned development path for future reference. If so, just force the push (with hg -f push) and create the abandoned branch. If you just want to forget everything about it, @Lasse's answer is just fine.