I concur to that. I find Hg branching model messy: there are clones, named branches, bookmarks and anonymous branches. They all have different features in term of how you can share them, etc... Also, I find comparing branches (through log, diff, etc...) a bit painful, especially because of inconsistencies between naming in hg - git naming is less user friendly, but much more consistent.

IOW, Git complexity comes from a f*cked-up UI, but hg simplicity is only superficial. Any semi-advanced usage in hg requires queues, a lot of plugins, etc... whereas git supports all that out of the box. Some simplicity in hg is also seriously broken - the "simple" version naming is a very bad idea in DVCS. Inevitably, different people will refer to the same revision (r1234) which is in fact a different revision because they are relative to different repositories.

Merging is also not that great in hg: I really miss git index when I need to resolve conflict. But I have a strong dislike for kdiff3 and that sort of tools.

I sort of like that revision naming, actually. As long as nobody does that, it does simplify things at times. Though no more than bookmarks do, and they can be descriptive instead of iterative.

The issue is exactly that people like it - everyone prefers a simple number to an hash, even if your name is Linus Torvald. But in DVCS, it is impossible to keep this naming consistent, and the cases where they work and don't may become quite subtle.

? you can "just branch and code" in mercurial too. I do it all the time.

I'm not sure where you're getting your info. Sounds like you might be still thinking that the FUD from 2008 that the only way to branch in mercurial is to clone a repo is actually true.

Check out the links in the post you replied to for more info.

With clones: article seems confused as to whether these are local clones or multiple remote repos[1]. If multiple remote repos: != branching, and horrendously wasteful. If local: almost exactly what I described, though they're making a repo for every existing branch; many other suggestions online suggest maintaining a "pristine", and it then becomes what I mentioned. And read the disadvantages section, it's pretty large. And this is one of the most-described means of branching; duplicating the repository because named branches are such a PITA.

Bookmarks: local only, no info ever reaches the server - ie, no label on a separate branch, it's just yet another anonymous branch.

Named branches: new head even when merged and closed, default push pushes all branches, so very difficult to use locally only if you have more than one remote branch (say, prod, qa, testing, dev. You now have to "hg push -b prod qa testing dev" just to prevent pushing your local branches. Or is it a separate push for each branch? I forget. And what if there were 20? 2000?). If you allow new remote heads, suddenly everyone will get tons of branches as you add more developers, name collisions / too many useful ones used up long ago (mybranch12a7c9?) - this is desirable how?

Anonymous: an artifact of any concurrent version control software, not a feature.

[1]: 2nd paragraph of: http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-me...

edit: summary: Git = friendly to multiple developers. Such as effectively every business environment. Mercurial = friendly to a single developer (in that case, yes, it's admittedly much easier), as long as you always push all branches.

Clones: I have seen a number of places talk about using separate repositories for branches in mercurial, but that's not how many people work these days. Just as with git, there are less efficient ways to do things.

In the article you linked to, the author is recommending against using separate cloned repositories, I agree with him.

Bookmarks: As of mercurial 1.6, bookmarks aren't local only and can be pushed.

Named branches: you don't have to push everything, just do

  hg push -r .

and it will only push the current revision, and any unpushed parent revisions. The linked article mentions this and talks about aliasing it to "hg nudge". If you do that, you have the same behavior as git.

I think git is a solid tool and that it can work well for many teams. I also know from personal experience at 3 different jobs that mercurial can work effectively for teams.

"hg push -r ." is new to me, though it makes some sense. How did you find that one out? "." is hardly a revision; it's a repository in every other command, from what I can remember (haven't used it since I initially learned mercurial).

And I'll have to see how well bookmarks function - not sure what my work repo runs.

"-r" is the revision flag for the revision to push out. "." is a shortcut that just means "the revision that the working directory is at" (same as hg identify would show).