[ubernostrum]

In terms of what you can actually do if you set your mind to it, they're not terribly different. In terms of the default/conventional things recommended by their communities, they're fairly divergent.

Speaking as someone who's used both and prefers Mercurial:

* Git's branching philosophy (lots and lots of branches, only one active at a time) can be handy. But Mercurial's philosophy (not quite so many branches, and usually as separate clones so you can work on more than one side-by-side) is, I've found, usually better.

* Git's much more encouraging of editing history up to the point where you share code with someone else. Mercurial will let you do that if you really want to, but it's discouraged; the only "easy" way is limited to undoing the last commit. Git seems to encourage committing much, much more often and not particularly caring about the repository history until you're ready to share with someone else (at which point you just selectively rewrite the history to look sensible). Mercurial seems to encourage committing in logical chunks so the repo history is clear and sensible the whole time (but again, if you really really want to do the Git-style stuff, you can).

* Mercurial seems to me, personally, to be a bit more logical in terms of choosing good defaults and exposing abstractions. Git's choices for default behaviors have been criticized even by its fans, and it tends to throw a lot of its inner workings at you on a regular basis, even if you don't really care much.

But, again, this is only my own personal opinion; undoubtedly others will disagree with it.

[jbellis]

> usually as separate clones so you can work on more than one side-by-side

the major downside here is that all IDEs I know are excellent at reloading your project from the fs when you git checkout a different branch, but much clunkier about having to reopen another directory.

[ubernostrum]

Which is why I said it's a trade-off.

If you go the git route, then you only look in one place for the code and it's easy to just point at it no matter what's currently active. But the downside is that (so far as I know) no tool other than git can show you what's in not-currently-active branches.

If you go the hg route it's easy to see lots of things side-by-side, but of course you don't have the "it's all in one directory, and you do have to point at different locations to work on different branches.

Personally, I prefer hg's approach here.

[rlpb]

If you want branches side by side in git, just clone your repository. Or am I missing something?

The one catch is that the "upstream" repository will be the local one you cloned from, rather than your original upstream. git-clone could easily have a switch for that, though.

[ubernostrum]

Notice that I've never said "git can't do this". I've been talking in terms of the conventions recommended by each tool's community. In the case of git, that's not separate clones for branches...

[maw]

Not taking a side on branching philosophies (other than that I think it's good to be branching lots), but git does let you do checkouts in multiple directories. It uses hardlinks (in the repo, not in the checkout, obviously) so it's fairly efficient in terms of space and time to perform the checkout.