Stuck with two default branches in Mercurial after broken branch commits

Question

I've come across a difficulty at work (as presented in the simplified sketch below). During the creation of a branch the default for some reason got stuck as a parent to a branch, but still keeping a default branch separately (that is the default branch we're using going forward). This has left us with two default branches.

Someone mistook how to commit changes before branching, so we ended up merging changes made in branch1 into a branch2.

I've been looking into Mercurial: the definitive guide to see if this is a resolvable issue, but couldn't find out what commands regarding backing out or closing that would help. The easiest way would be if it's somehow possible to rename the left-over default branch.

What is the best and/or easiest way to resolve this?

I'm preparing the merging of development branches into the correct default branch and want to have this headache fixed before I start any major merging that could make it even more difficult to fix this in the future.

Answer 1

Remember that the branch names are just labels put on the commits — there's nothing really broken about your graph. The branch names doesn't affect what happens when you merge, only the file content is important when merging.

That being said, you can close the extra head on default, the one below branch1:

$ hg update "min(heads(branch(default)))"
$ hg commit --close-branch -m "closing this head"

That will leave a dangling close changeset in your graph, which is fine. The close changeset will hide the head from hg heads and commands such as hg merge will then no longer suggest to merge with this head.

Answer 2

Old question, but I though this might be useful to someone.

..this occurs when a single branch diverges, usually when someone does an hg push -f instead of pulling and updating. In your case, the forced head happens to be also on another branch, but this can happen on a single branch as well. My solution would be to let it sit until the branches are merged -- at least, if there's a plan to merge them at some point. This solution is more clean than closing the erroneous head, in my opinion.

However, doing hg update default will take you to the newest commit with the 'default' name. Although I think this idea is the right one in your case, this is because the "default" that you actually want is the newest commit with the "default" branch name, so there should be no problem.

However, if the erroneous head were newer, hg update default would take people to the erroneous head, which could be quite confusing.

In either case, this would resolve the issue:

hg update <revision number of correct 'default' head>
hg merge <branch the erroneous 'default' head is on>

So in this case, hg update default will update to the erroneous head:

1-2(default)
 \
  3(default)-4(branch1)

You would need to do:

hg update 2
hg merge branch1
# results in this graph:
# 1-2---5(default)
#  \   /
#   3-4(branch1)

whereas below, hg update default will update to the one you actually want anyways:

1-2------------5(default)
 \
  3(default)-4(branch1)

..and you could just ignore the erroneous default, because it won't affect anyone. ..then, once someone does an hg update default; hg merge branch1, the erroneous head will silently disappear, because at that point it's an ancestor of the erroneous 'default'. ..which would result in something like this:

1-2-5----------11(default)
 \            /
  3-4-[...]-10(branch1)

..you could also do a useless commit on your desired default, and then it will be the newest, and it would be the one people get when they do hg update default, but I don't really like having junk commits in the history.