Git just has a directed acyclic graph and pointers to the nodes of it. That's all. End of story.

Mercurial has the concept of a branch, a tag and so on as seemingly separate axiomatic things. It's not as stupid.

I like stupid.

Arguments can be made for both sides, picking a single design decision and saying that that’s obviously better is not going to work. Implementation and (especially in a case like distributed systems) network effects are much stronger than any single isolated design decision.

I would argue that in the case of Git it's not about a single design decision. The whole design is very simple and easily understandable. Thus everything can be derived from the design decisions.

The design decisions also have clear rationales.

"Why something is better" and "why something has "won"" are of course different questions that deserve different answers.

Of course, I may also be a terrible teacher.

I find it easy to teach, thanks the concepts being simple and clear. I don't have to transfer a lot of information before people can start reasoning about things themselves and independently finding out more.

I always try to make sure people understand two things:

1) The history tree (==how to read the metro-map that is gitk)

2) Distribution, that you are responsible for syncing with others, not the other way round

Almost everything else I prefer the students at least try to figure out themselves.

And of course, if mercurial could give me more features, I'd probably think twice. However, it's practically equivalent to git.

I was comparing git and mercurial, not giving the one true testament to comparison of every possible version control system.

If most of your work is done with one group of people inside your company and you decide mercurial is a better fit it would seem silly just to go with git because it is popular.

Besides the two are similar enough that someone versed in mercurial should be able to learn enough git to be useful quickly enough should it be required.

And I'm not saying you should choose git because it's better. I'm saying git "won" in the community because it was the choice of people who want to play in the community. Culture matters, and hg's proponents, for whatever reason, are less likely to want to share their stuff.

Do hg people "share less" or are there simply less of them? IIRC github allows commits from hg as well as git.

And of course not everyone (in fact possibly only the minority) is interested in cloning and issuing pull requests on OSS a huge amount of programming happens internally in corporations where everyone will use whichever VCS is mandated.

Subversion was indeed a much better CVS than CVS. And the world almost jumped on it as a standard. But then git appeared. If you were a young person looking at building exciting projects from source, you might never have reason to learn svn. I think that qualifies as "forgotten"

Network effect: many many people pick git because everyone else uses it (and that’s a good reason), thus they never try Mercurial, which may or may not be better suited to their use case.

I have some code in Git with my custom patches, with upstream being Hg. `git-hg' works like a charm -- simple, clean etc. etc.. Dunno what you are talking about here.

Git provides git-fast-export & git-fast-import as two-way interconnects, with well-defined data formats.

I clearly didn't, too, so I deleted the post.

2) Git is trivial to extend. If something for git doesn't exist that does not suggest any sort of arrogant attitude from git, but rather just a total lack of interest from both the developers and the community.

Using loaded terms to put down people who use the tool they prefer isn't going to convince anyone that your argument has merit.

[1] Now that you've drawn attention to it, I do indeed wish I'd phrased that differently. But certainly not because I hurt someone's feelings...