Using an acyclic graph of chained hashes to represent change history has a long history in revision control - it was used in Monotone (which Linus considered as an option instead of writing git, but rejected as it was written in C++), in OpenCM, in Xanadu, and probably in at least half a dozen other systems I've never heard of.
Small correction, Linus rejected Monotone because it had been horribly slow on the huge Linux source tree. Git was focused on performance from the outset, where Monotone cares more about integrity and correctness than speed.
That said, it's definitely true that Linux has strong and negative opinions on C++.
Well, one of the big problems in Monotone back in the day was that since they (we? I contributed a bit to Monotone, but was never a core contributor) broke people's repos several times with data integrity bugs, and so got very paranoid and added lots of slow integrity checks to make sure that didn't happen any more. Part of the reason for the breakage was that they were still experimenting with the basic representation of history, merge algorithms, and the like, and so had to do data migrations quite often, which sometimes introduced bugs.
Git had the advantage that it could learn from Monotone's mistakes, and focus on speed, and not have to experiment as much since much of the basic design ideas were already there. Git also made several better architectural choices, I believe, going with a much more simple and stable repository format than Monotone had.
I think you have to take what he has said about C++, or OO in general in context. What he said (at least what I've read) was that C++ would never make sense for the kernel, and his reasoning seems sound to me
I've always taken the opinion that OO makes sense where one needs the ability to model abstract systems in a way that can express and even explain them through the code. Modeling an computer doesn't require or benefit as much from such abstractions.
It's not only about kernel, see this thread from the Git mailing list:
"C++ is a horrible language. It's made more horrible by the fact that a lot of substandard programmers use it, to the point where it's much much easier to generate total and utter crap with it. Quite frankly, even if the choice of C were to do nothing but keep the C++ programmers out, that in itself would be a huge reason to use C."
I'm pretty sure the head Mercurial developer was subscribed to the Git mailing list and decided to build his own DVCS when he saw Git wasn't heading in the direction he wanted. Mercurial might have been released earlier, but it was definitely a reaction to Git rather than convergent evolution.
As I understand it, Mercurial development was started as a reaction to this mail where Torvalds states that the kernel team is looking for Bitkeeper alternatives: http://lkml.org/lkml/2005/4/6/121
Really? It's still early days in the DVCS "wars". :)
I use git and I love that it's faster than Mercurial (a couple of years ago, I timed 'git log' at 1 second and 'hg log' at 13 seconds on same repo contents).
But precisely because it's written in hard-to-modify, hard-to-library-ize C code with several Linux dependencies (afaik), many companies are choosing Mercurial (Google, Kiln, Atalassian).
I can easily imagine a future where Mercurial has far more plugins/extensions than git (because it's easier to write Mercurial plugins) which will be a huge advantage in Mercurial's favour (a la Firefox). For such reasons, it's likely I will switch to hg one of these days.
It may only be a matter of time before Mercurial catches up with git's performance and becomes the de-facto standard, and git is relegated to the Linux kernel and other early adopters.
Other than the index all my git knowledge directly translated to Mercurial. I myself am planning to switch as soon as I can overcome inertia and go through one of the tutorial.
