Well, that's one biased post.<p>In "bookmarks are not enough", the author claims that that the commits just stay there after deleting the bookmark - the horror! Actually, the same thing happens in git. Commit unreachable via names will stay around until you run garbage collection. You can still see them in reflog.<p>"Anonymous heads" - yes, that exactly why `hg push` warns you. Exactly the same reason rebase warns you that it's destructive and pull rebase isn't the default. So you don't make a mess by accident. If you want to see what's available in the remote repository, like after `git fetch`, you can see the new commits via `hg incoming`.<p>I can't agree with "Nothing is lost" either - the tree he presents is trivial. Give it a go on a repository with 10+ topic branches which are re-synched to trunk a number of times and with more than 2 commits. Suddenly getting everything labelled with branch names is much more useful.<p>I'm not against one system or another, but having a fair explanation of both systems would be nicer than a blog saying pretty much "it's different than git, therefore it's bad". In the end it's down to personal preferences. Some people find "branch labels" more comfortable to work with, some prefer "branch bookmarks". That's it. Yet every once it a while we get a long "but this is so much worse than git!" explanation. Great, I'll keep using hg because I like it better, thank you very much.
This goes a long way towards explaining some of the things I don't like about Mercurial but haven't ever fully understood. I didn't even realize the git and mercurial concepts of branches were different!
> When you are done with the ‘quick-fix’ branch, you can just remove it, and nobody has to know it existed<p>Well, I actually want to know about branches. If someone finishes work on some branch, he'll just close it after merge. Also, "hg branch" command will sort out non-merged branches from merged. This is so handy.<p>One thing that bugs me in git branches is that only gitk shows branches (in git's strange way, when topmost commit has tons of branches assigned to it), while in mercurial nearly all clients show branch info beside commit, since it's a core feature and it's stored in commit.<p>I am now working with git for >6 month (after >1 year work with hg) and every time I feel some mess with branches/merges it feels very uncomfortable.<p>So, for non-huge projects, hg branches are super-great, imo.