Mercury branch of change history, two remote heads when pressed

Question

I made a bunch of change sets locally (23-28) and then 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 made a few changes. Now I am ready to push my changes to the server, but when I try to do this, he complains about "abort: push creates new deleted chapters on the default branch!". I thought that someone else might have taken over the repository, so I did hg pull but didn't get any changes.

Here is the revision tree I'm working with

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

Is it possible to delete revisions 26.27 and 28? How can I fix things so that I can run "hg push" without errors? Should I use another command to return to revision 25?

Answer 1

Well, there are two ways that I know of.

Note. Please create a backup copy or clone for experiments, I will not take responsibility for any lost work.

First, if you have enabled the MQ extension, you can disable it. I only know how to do this using TortoiseHg, but I will find the right commands after posting here.

To do this, you run the following command:

 hg strip 26 

---

Secondly, you can create a new clone locally from only some change sets , again I only know how to do it using TortoiseHg .

To do this, you run the following command:

 hg clone SOURCEDIRECTORY CLONEDIRECTORY -r35 

Then, from your clone, after verifying that it contains the changes you need, you click on the target repository.

---

Regarding the answer to what you were supposed to do, you could remove your original clone and re-clone from the server to get a clean clone containing only 25 changeset, but of course you could use the strip command to get rid of then redundant sets of changes.

Answer 2

Let me just pounce on the voice of dissent at Lasse's answer. Mercurial is a system for building an immutable story. Think of a scientist who works in his lab book on numbered pages in a pen. Everything is important, even what you want you to not write and do not want at this second. By default, the strip command is not enabled by default - it violates the immutability, which is the goal of merurization.

The more "mercurial" way to solve this problem should be to combine 26 into 35, fully selecting options from 35, so that you return to one head. Then your push will still have only one head, but the whole story is saved.

Alternatively, you had the “hg push -r 35” option, which would not give you any warnings or errors or require -f, because you will leave the repo repo with only one head.

There is nothing wrong with the strip, but it is not part of Mercurial’s traditional set of tools or thinking.

Answer 3

There is nothing wrong with having many goals - Mercurial just checks what you want. In this case, you may need to leave the abandoned development path for future use. If so, just force push (with hg -f push ) and create an abandoned branch. If you just want to forget all about it, @Lasse answer is great.