Fixing the 'repository has at least one unnamed head' error when converting a Mercurial repository to Git

I was following the "Migrating to Git" instructions and run into an issue while converting our Mercurial repository. The fast-export script displayed the message: "Error: repository has at least one unnamed head: hg r3419".

My first move was to check the revision 3419. The revision was a 'close branch' commit on a named branch. Nothing special and that was confusing.

It took me a while to realize: the error means there is a branch with more than one head. Now it seems pretty obvious :)

The following command produced me a list of branches along with the number of heads:

hg heads -c | grep branch: | uniq -c | sort

It turned out, there was an old, closed branch with two heads. Each head was closed with a separate commit. The solution was to merge these heads and close the branch once again.

I hope this post might help in case someone else runs into this issue.

Mercurial: an incident with "hg pull --rebase"

Our team uses Mercurial. Some time ago we started using rebase instead of merges to have clean linear timeline. The rebase approach seemed to be straightforward and almost automatic. But recently we run into an issue: a code from the development branch leaked into the stable branch, the branch that is indended for bugfixes only.

Below is a reconstruction of the incident. While it might appear to be a lot of text, it is actually just a couple of commits, so please don't be scared and read on.

Consider a team of two developers - Leo and Penny - working on a product. The product's repository has two branches: 'default' and 'stable'. New features are being developed on the 'default' branch. Bugs are fixed on the 'stable' branch. From time to time the 'stable' branch is merged back into the 'default'.


hg init repo
cd repo
@echo > product.cs
hg add
hg commit -u leo -m "initial version"
hg branch stable
hg commit -u leo -m "creating 'stable' branch"

1. Leo fixes a bug and pushes his changes:

hg clone repo repo-leo

cd repo-leo

hg up stable

@echo > bugfix-01.cs

hg add

hg commit -u leo -m "fixed: bug-01"

hg push

2. Penny fixes a bug and merges the 'stable' into the 'default':

hg clone repo repo-penny
cd repo-penny
hg up stable
@echo > bugfix-02.cs
hg add
hg commit -u penny -m "fixed: bug-02"
hg up default
hg merge stable
hg commit -u penny -m "merged bugfixes into the default branch"

3. Penny writes a new feature:

hg up default
@echo > new-feature.cs
hg add
hg commit -u penny -m "new cool feature"

Penny's repository: bug fixed, feature implemented.

4. Now Penny wants to push her changes:

hg push
pushing to C:\Temp\repo
searching for changes
abort: push creates new remote head 4fa702a0c723 on branch 'stable'!
(you should pull and merge or use push -f to force)

But the server aborts the push. Penny understands that someone has already pushed changes, so she does a regular routine: pull --rebase

hg up stable
hg pull --rebase

Damage is done!

Penny's repository before rebase

Penny's repository after rebase. A code from the development branch is now on the stable branch.

Look at the screenshots illustrating Penny's repository before and after rebase. Notice the "new cool feature" changeset that should be on the development branch. Now it is on the branch 'stable' and that should have never happen...

(to be continued)