Maybe this is a not-so-frequent thing, but I know it's not just me: As I see it, the big advantage of Git over other attempts at DVCS is that its internal model of the world is very simple and just right.
Early on when Git was still new, I read about the different types of objects (files, trees, commit objects) and how they interact, and everything just clicked. It's the correct model for version control, and I like to believe that that's why it's winning.
In fact, all your praise for Git is something that, as far as I see it, flows directly from Git having the correct model for version control.
I don't think git's model is particularly special in any way - if it were, it wouldn't be possible to make (near) transparent proxies to the other DVCS's.
The fundamental concepts in all the DVCS's are almost indistinguishable; they're just packaged slightly differently.
It's tempting to seek a technological explanation for git's dominance; but all the obvious signs point to it simply being first-mover advantage. Where the other DVCS's do have technical advantages, they're rarely very significant for most people.
Funny you should say that, Git's fast-import format was adopted by most DVCSes for easy transfer of commits from a foreign repository. Transparent-ish proxies do exist, like git-remote-hg. Those others have different models for history (Bazaar uses folder-type branches, Hg's branching is also different) but Git's internal model is a common subset.
But Git was not a first mover. That simple model was pioneered by Monotone. Git won because Linus' use case required high performance. DVCS flows from that (no waiting on the network), as does the index, and it just made for a huge difference in user experience.
I'd forgotten about monotone - my focus was on today's choices, and monotone isn't exactly alive nowadays ;-).
git+hg share the same model for history; that's a DAG of commits. Sure, there are differences, but they're rather superficial. One such difference is in how you, as a human, categorize commits in that dag - what git calls a branch isn't what hg calls a branch. But so what?
In day-to-day use I can't imagine that the vast majority of git users would really notice a ifference if they used hg instead; and I suspect the same thing holds for bzr too. There's no meaningful performance difference. But the point is also that reverse is mostly true too - why not choose git it it's good enough?
And then git's real advantage shines through - it's by far the most common, and that lets you cooperate with a large number of other developers simply because lots of people know git. Oh, and github is popular too and git-only. Then there's the fact that bzr seems dead, as does monotone. The advantage is largely social - though if the currect pace of development continues it way well become technical.
Git definitely wasn't a first-mover. Being used by the Linux kernel probably helped, though. (Though the Linux kernel actually used a different DVCS before Git...)
Early on when Git was still new, I read about the different types of objects (files, trees, commit objects) and how they interact, and everything just clicked. It's the correct model for version control, and I like to believe that that's why it's winning.
In fact, all your praise for Git is something that, as far as I see it, flows directly from Git having the correct model for version control.