Why Hg branches are broken (or at least less useful)

In one picture:

In Hg, branches are metadata included in each changeset.  In the operation above, I created a branch, but that only marked the current directory with a branch name.  The branch won’t actually show up unless I make a commit.  In fact, if I checkout to another revision, it’s as if the “hg branch” command never happened.  When I list the branches, you won’t see this new branch name.  The name in the PS window just comes from the PowerShell-Hg extension being smart.

One implication is that our team has to make phantom commits for the branch to officially “show up”.  You start to see commits like “phantom commit” early on, then later they start saying “stupid commit”.  It’s the only way we could get a branch to show up locally and on the server.

In Git, a branch is nothing more than a pointer to a commit, and the commit itself carries no information about a branch name.  A much more flexible model in my experience.

This hit me today when I wanted to move a set of commits to a different branch, which turned out to be very difficult as the branch name was embedded in to the commit names.  Rebasing helped, except that the commits were already pushed to the server.  We wound up having to back out of the commits, even though these were on a different logical branch, simply because our build server got confused about these extra commits that were marked with the wrong branch name.

Perhaps Hg branches aren’t broken and this design is intentional.  But it’s annoying and less powerful and flexible than Git’s more simple model, of just a pointer to a commit.

Side note for the Git folks – I’ve also wasted 2 hours of my life on Git when my .git folder suddenly went empty – and not from me accidentally deleting anything.  Lost all my dangling topic branches on that one.