Fanning the flames of the Git vs. Mercurial debate

Honestly, posts like this are just detrimental to both communities. They're immature and show a complete lack of understanding of software development. Choosing the right tool for the job is rarely easy as "high level" and "low level".

Git was created to solve a specific need: Distributed development of the Linux kernel. The fact that it's been adopted by so many developers outside of the Kernel community shows that it is at minimum an adequate tool for the job. I'd go ahead and say, for those developers, Git > Mercurial. That's why they choose it.

For the developers who choose Mercurial, Mercurial > Git. That's why they've chosen Mercurial.

Please, before you publish stuff like this, remember that we're all on the same team. Next time, advocate Mercurial by talking about how it's improved your workflow. Talk about why Mercurial is better than Git for you, perhaps talk about the technical differences of the underlying implementations on a conceptual level.

That way, maybe you could help someone make an informed choice about what to use, instead of basing their decision on something as silly as the language it's written in.

In the end I think what you're saying is relatively intuitive but the internet needs less arguments based on value judgments, and more discussion centered on things we can point to, at the very least, as generally agreed upon facts.

Yes and no.

The workflow for managing branches is different, because you usually just clone an hg repo to do a branch, and then merge as needed.

The workflow for more complex things isn't quite as different as most people seem to think, though; mainly the difference is that in hg the answer is "use a patch queue". Operations on patch queues are somewhat lower level than, say, git's rebase, but all the power is still there (and there's a rebase extension which will let you do it all in one go if that's your thing).

What's been interesting to me is seeing the evolution of the "popular" git workflow over time. Originally, people hyped things like rebasing and editing commit history, but gradually the emphasis has shifted away from that and the best practices have solidified around using those features only when they're necessary, which is much less often than a lot of folks originally believed. And, amusingly, that's very close to the way hg has always been used: you can do lots of fancy stuff, but you should have a good reason for doing so (and should typically never do so after you've pushed to other folks or they've pulled from you).