3 ms·

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

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.

JoelMcCracken 16y ago
I would have thought so. Hashes aren't so special as to warrant all that attention.
adambyrtek 16y ago
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++.
- lambda 16y ago
  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.
- lucisferre 16y ago
  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.
  - adambyrtek 16y ago
    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." http://thread.gmane.org/gmane.comp.version-control.git/57643/focus=57918 http://thread.gmane.org/gmane.comp.version-control.git/57643...
    - lucisferre 16y ago
      And that may be a fair criticism of C++ specifically, I don't know I don't really use it.
wcoenen 16y ago
Also, Mercurial 0.1 was released before git was usable: http://mercurial.selenic.com/wiki/Presentations?action=AttachFile&do=get&target=ols-mercurial.pdf http://mercurial.selenic.com/wiki/Presentations?action=Attac... All the ideas were already there. Somebody just wanted his damn DVCS to be written in C :-)
- thristian 16y ago
  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.
  - wcoenen 16y ago
    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 http://lkml.org/lkml/2005/4/6/121 Git didn't exist yet at that point.
- burgerbrain 16y ago
  >Somebody just wanted his damn DVCS to be written in C :-) Who can blame him? Certainly nobody can criticize the decision these days and keep a straight face. Results speak louder than ideaology.
  - anonymous246 16y ago
    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.

JoelMcCracken 16y ago

I would have thought so. Hashes aren't so special as to warrant all that attention.

adambyrtek 16y ago

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++.

lambda 16y ago
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.
lucisferre 16y ago
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.
- adambyrtek 16y ago
  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." http://thread.gmane.org/gmane.comp.version-control.git/57643/focus=57918 http://thread.gmane.org/gmane.comp.version-control.git/57643...
  - lucisferre 16y ago
    And that may be a fair criticism of C++ specifically, I don't know I don't really use it.

wcoenen 16y ago

Also, Mercurial 0.1 was released before git was usable: http://mercurial.selenic.com/wiki/Presentations?action=AttachFile&do=get&target=ols-mercurial.pdf http://mercurial.selenic.com/wiki/Presentations?action=Attac... All the ideas were already there. Somebody just wanted his damn DVCS to be written in C :-)

thristian 16y ago
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.
- wcoenen 16y ago
  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 http://lkml.org/lkml/2005/4/6/121 Git didn't exist yet at that point.
burgerbrain 16y ago
>Somebody just wanted his damn DVCS to be written in C :-) Who can blame him? Certainly nobody can criticize the decision these days and keep a straight face. Results speak louder than ideaology.
- anonymous246 16y ago
  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.