[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...