Comment Re:April Fools! (Score 1) 162
The main practical difference, past the API, is their approach to branching: A git branch is a mercurial bookmark. There are no concept like mercurial's branch in git. There's also how git has this crazy staging area that is the cause of 90% of bad commits to our git repos. Commits that are missing a file, or have an extra file, are the bane of SVN and Git repos. In hg, the expected behavior is commit everything that is not in a patch. More discipline required, less chances of shooting yourself in the foot.
As far as the interface goes, other than the well known stuff, there's the fact that default behaviors seem to be all built around pulls, not pushes, so if your typical corporate environment, where pulls are often nonsense, people get very confused when 'natural' behaviors tell them that the files that changed from a merge are the files from the upstream, that they did not edit, and things like that. To minimize it, I keep telling people to avoid git pull like the plague, and instead use git fetch, followed by git rebase as the baseline case.
Either way, both are pretty useful, and beat SVN in almost all use cases. I just think that it's easier to teach people hg than telling people to learn a bunch about git internals before they can contribute properly.