I agree with the superficial things for the most part, though it should be pointed out that 'hg revert .' and 'git checkout .' do basically the same thing - the

I agree with the superficial things for the most part, though it should be pointed out that 'hg revert .' and 'git checkout .' do basically the same thing - the 'git reset --hard ORIG_HEAD' example is way more complex than it needs to be and is a bit more harsh than he's asking for. The one big issue is the branching comments. Creating named branches like he's doing here is very problematic, especially if you're at all used to Git branches. Running '--close-branch' doesn't really remove the branch, it adds another commit that has some metadata saying it's closed - but older versions of hg won't recognize that (the feature is very, very new - it was introduced in 1.2) and even if you have a version of hg that supports it, the last I tried it won't hide the closed branches by default, you have to provide a switch to 'hg branch' to hide them ('hg branch --active'), which is pretty annoying. If I created named branches for all the topic branches I've made in my various Git projects, I'd have hundreds or thousands of named branches littering up many of them. There are tons of other serious problems with Hg's concepts of lightweight branching - for instance, you can't NOT push all of your branches to a repo when you push, meaning you can't have any branches that are just for you to test stuff out in - if you create what Git users think of as a 'topic branch', it's basically there forever - no way to ever really remove it or not share it. If you use the Bookmarks extension, which is meant to more closely mimic Git branching, you have the opposite problem - you can't push the bookmarks up to a shared server, you have to SCP them separately. I believe the heads will be there, but that's even more confusing because now you just have a bunch of unnamed heads... Speaking of namespace issues, named branches are way worse for that - if you create a named branch locally and someone else creates the same named branch locally and then you clone from them, you'll have two heads with the same branch name, which could have totally different lines of work on them and Hg doesn't complain - that could get ridiculously confusing. Most Hg users I know only very rarely use named branches - the online book recommends doing a local clone instead of a named branch for branching. Many serious Hg users instead use the 'mq' extension, which provides a patch queue toolset for Hg and allows you to do some revlog editing - allowing you to do development much more similarly to how Git devs do, but the toolset and paradigm are _much_ more convoluted and confusing than the problems he states about Git branches, IMHO. There are certainly a number of UI improvements that Git could make (and Hg, too) but I really don't think Hg's branching model is something to emulate.