My initial situation is similar to the one in this question. Coming from a strong Git background, I wanted to force-push a cleaned-up version of my private branch (under the same name) where I’ve squashed / folded some commits (using the histedit extension). What I did again is similar to this answer, but I did things in a different order:
$ hg clone -b private_branch <url>
$ hg histedit -r <some_rev> # Fold some commits
$ hg push -f # This creates a second branch head on the server
$ hg update -r <rev_of_original_branch_head>
$ hg commit --close-branch -m 'Closing this branch in favor of a cleaned-up version'
$ hg push
The thing I don’t understand is, if I now set up a new working tree, I get
$ hg clone -b private_branch <url>
$ hg log -l 1
changeset: <rev>:<sha1>
branch: private_branch
tag: tip
parent: <tip_rev_of_branch_before_folding>:<sha1>
user: <name> <email>
date: Wed Aug 08 11:48:25 2012 +0200
summary: Closing this branch in favor of a cleaned-up version
Why is tip pointing to the closed branch? hg heads is only showing my force-pushed head as expected. However, hg heads -t is showing both heads for private_branch. I’ve also verified that my closing commit is indeed a closing one, hg log --debug shows extra: close=1.
EDIT: The problem with this is, if I do a commit on a fresh clone, I get
$ hg ci -m "test"
created new head
reopening closed branch head <rev>
But I do not want to reopen the closed branch head, I want to commit on top of the open branch head.
How can I fix this, preferably without doing a no-op merge?
The solution was to simply do
to set the working directory’s parent revision as shown by
hg parent(s)to the newly created open branch head, away from the closed branch head. It was somewhat unintuitive to me that I needed to “switch branches” although I already “am on that branch”, but in this case I was not switching branches, but switching heads within a single branch. Something that works completely different than in Git.