4 ms·

A fascinating bit of history is that the reason for this data structure was to explicitly distance git from BitKeeper. BitKeeper was used by many kernel develo

A fascinating bit of history is that the reason for this data structure was to explicitly distance git from BitKeeper. BitKeeper was used by many kernel developers, until one of them (the co-inventor of rsync, unsurprisingly) reverse-engineered its protocol, leading its proprietary owner to end its offer of a free license to Linus Torvalds and other developers. While searching for a replacement, the Linux community sparked two projects: Mercurial (which uses changesets, similar to BitKeeper) and Git (which uses Merkle trees). Git was created by Linus in the unexpected free time that this event created; and he mentioned being weary of Mercurial and having adopted this design for Git to remove any ambiguity that they were creating a BitKeeper clone. Incidentally, BitKeeper did demand that its customers not work on Mercurial[1]. [1]: https://web.archive.org/web/20070929115009/http://article.gmane.org/gmane.comp.version-control.mercurial.devel/3481 https://web.archive.org/web/20070929115009/http://article.gm...

feoren 6y ago
I wonder if this is why Mercurial is so much simpler and easier to understand than Git -- precisely because Git was forced to adopt a more "out there" approach. Personally I'm sad Git won out over Mercurial -- the latter is a much better technology from my experience.
- war1025 6y ago
  > Mercurial is so much simpler and easier to understand than Git I think it must just be a mindset thing. The way git works makes perfect sense to me and I don't know why you would do it any other way. But git was already gaining significant traction when I started using version control. I can see how having built your mental models around previous version control systems and then trying to superimpose that on git would cause dissonance. But my entire concept of version control is based on how git does it, so it seems perfectly natural.
  - yoz-y 6y ago
    Underlying technology aside, mercurial has (I think) quite objectively better cli interface. All flags are the same among commands, and all commands have their undo counterparts.
    - rualca 6y ago
      > Underlying technology aside, mercurial has (I think) quite objectively better cli interface. I disagree. The fact that mercurial relied extensively on extensions to implent basic features, thus exposing a non-standard interface to the world, made it's mental load significantly higher than simply using a standardized (albeit debatable) interface to do standard things. Case in point: requiring installing extensions to stash local changes.
      - throwawayzRUU6f 6y ago
        > relied extensively on extensions to implent basic features Sorry, this is a strawman. Yes, `hg shelve` is a very nice extension. But that's about the only add-on I've ever needed, while working more than 7 years on reasonably complex projects spanning about a dozen teams, in multiple timezones and repositories. And it takes less than 5 minutes to install. We were forced to move to Git after being acquired, and while the migration was painless, the day-to-day friction caused by Git porcelain is notably higher than with Mercurial. The issues caused by line-endings alone waste more time than all the Mercurial issues combined.
        rualca 6y ago
        > Sorry, this is a strawman. It really isn't,and you cannot hide Mercurial's failings by trying to move the goal post. It's a fact that Mercurial's non-standard interface created a mental load for basic ops that is considerably higher that git's reliable and predictable (and, more importantly, learnable) interface. > Yes, `hg shelve` is a very nice extension. But that's about the only add-on I've ever needed. It's not a "nice extension". It's core functionality, which is a part of any basic introductory workflow. And with mercurial instead of just being able to stash changes with a simple $ git stash , all of a sudden you need to bother with installations and setups and configs and checking if everything is it's place. Just. To. Stash. A. Change. And if you find stashing nothing more than "a nice extension", and nothing else pops into your mind, then you clearly have limited experience in using revision control systems. > And it takes less than 5 minutes to install. Did you failed to notice that it forces you to waste time ensuring you're bolting on all the stuff you need whenever you jump a seat or pop into an instance? And did you failed to realize this problem is not experienced with pretty much any revision control system? Not just git, but pretty much all of them.
  - laurencerowe 6y ago
    While Git is conceptually beautiful, it's CLI seems something of an afterthought and is maddeningly inconsistent at times.
  - mumblemumble 6y ago
    It's, of course, impossible to do a practical experiment where someone doesn't learn, and therefore become biased toward, one of them first, and then learn the other after. For my part, what I can say is, I used Mercurial for one year, and Git almost exclusively (I do occasionally touch Subversion) for a straight decade after that. And I still find myself having to consult Git's documentation far more often than I ever did with Hg. And, even now, I find myself having to un-pick minor screw-ups in Git more often than I did after only a couple months on Mercurial. I'm pretty sure that the problem here is ultimately the UI and not the data model. No, I'm sure it is. Every time there's a conversation about Mercurial vs Git, and someone says, "Git's not that bad, all you have to do is learn the data model, and then learn all the different ad-hoc ways the UI is bound to it," my immediate thought is, "You see, that's exactly the point. The thing that's nice about Hg is that you don't have to take this extra learning step, because the data model and the UI model are one and the same." Also, merge conflicts seem much more common in Git. I'm not sure if that's a UI problem or a data model problem; I could see it being either or both. In any case, I felt much more comfortable allowing branches to live for days in Hg. In Git, branches that survive past 24 hours seem to always result in either shaving or getting trampled by yaks.
  - kelnos 6y ago
    As another data point, I used CVS and later SVN for years before I used git, and I find git to be incredibly easy to use and understand. But I've been using it for over a decade, and spent time in the early days to understand how it works under the hood. This isn't to say git has a good user interface. I don't think it does. I'm comfortable with it because I've spent many years using it, and because I expended extra effort (effort I don't think an average user should have to expend) to learn it well, and to be unafraid of making mistakes while poking around.
- lowbloodsugar 6y ago
  I know git is confusing on the one hand, and somehow instills over-confidence on the other. But the underlying implementation of "Store everything, SHA it, and build a merkel tree" is, in my opinion, the kind of thoroughness I want in a version control system.
- brodie 6y ago
  Short of breaking backwards compatibility at this point, there’s nothing preventing Git from being as simple as Mercurial CLI-wise. The two projects are nearly identical on a high level.
DoofusOfDeath 6y ago
I forget - was there another side to the story that made McVoy's actions seem more reasonable? If all I had to go on was Bryan O'Sullivan's email, I'd be tempted to draw some unflattering conclusions about McVoy's conduct.
- espadrine 6y ago
  Mercurial was officially named after Larry McVoy. (No idea about git.) That said, in his defense, causing the creation of multiple open-source competitors to one’s moneymaker can be stressful.
  - ben509 6y ago
    > (No idea about git.) Quoth wikipedia[1]: > "I'm an egotistical bastard, and I name all my projects after myself. First 'Linux', now 'git'." [1]: https://en.wikipedia.org/wiki/Git#Naming https://en.wikipedia.org/wiki/Git#Naming
- kelnos 6y ago
  I read a lot of the mailing list threads back when all this was going on, and I don't recall feeling any particular sympathy toward McVoy at all. The fundamental issue I saw was that McVoy decided to foist what I consider an unconscionable license agreement upon his unpaid open source users: users were prohibited from working on another version control system without having their license to use the read-only BitKeeper client revoked. (And reverse engineering BK's protocol was also forbidden.) From the starting line I already thought he was slimy for that. This is where Torvalds should have gotten his big honking "I told you so", but I expect he took the wrong lesson from it since he was able to whip up an acceptable alternative in git in a fairly short amount of time[0]. Anyway, McVoy was usually pretty civil in email threads about the whole thing (likely with a few angry words here and there), but I don't think that really mattered to me: IMO he was asking something unethical of his users from the start, and so I think ethically Tridge was completely in the right to reverse engineer BK's protocol and write an unencumbered client. McVoy's response to take his ball and go home was of course entirely within his rights, but was oh so childish. And, surprise, BitKeeper has since failed as a product; I believe it's now open source, and has a tiny fraction of git's user base. [0] I think it's easy for some to take the -- IMO mistaken -- view that "being allowed to" (eye roll) use BitKeeper was a "generous" gift, because it pushed someone to build a viable open-source alternative when their back was against a wall. My view is that it was just lucky for the open source community that McVoy went up against one of the few people with the talent and motivation to out-build BitKeeper. This is one of those times RMS's preaching against using closed-source software is so spot-on, publicly, painfully correct.
mkj 6y ago
Isn't Mercurial different only in nomenclature? The manifest id stored in a changeset is a tree snapshot. Otherwise I don't think hg-git would work as transparently as it usually does. https://www.mercurial-scm.org/wiki/ChangeSet https://www.mercurial-scm.org/wiki/ChangeSet
- brodie 6y ago
  They’re different in the their implementations of how repositories are stored on disk. Other than that, you’re right in that the two systems have a gigantic (almost one to one) abstract/conceptual overlap.
- espadrine 6y ago
  They did add it; I think it wasn’t there in v0.1[0]. Nowadays, the revlog contains a sequence of either snapshots or deltas[1], a bit like video codecs I-frame and P-frame, except the heuristic is how much data must be read to check out the file; so most are likely deltas. [0]: https://lore.kernel.org/lkml/42692470.9050605@tmr.com/T/ https://lore.kernel.org/lkml/42692470.9050605@tmr.com/T/ [1]: http://hgbook.red-bean.com/read/behind-the-scenes.html http://hgbook.red-bean.com/read/behind-the-scenes.html

feoren 6y ago

I wonder if this is why Mercurial is so much simpler and easier to understand than Git -- precisely because Git was forced to adopt a more "out there" approach. Personally I'm sad Git won out over Mercurial -- the latter is a much better technology from my experience.

war1025 6y ago
> Mercurial is so much simpler and easier to understand than Git I think it must just be a mindset thing. The way git works makes perfect sense to me and I don't know why you would do it any other way. But git was already gaining significant traction when I started using version control. I can see how having built your mental models around previous version control systems and then trying to superimpose that on git would cause dissonance. But my entire concept of version control is based on how git does it, so it seems perfectly natural.
- yoz-y 6y ago
  Underlying technology aside, mercurial has (I think) quite objectively better cli interface. All flags are the same among commands, and all commands have their undo counterparts.
  - rualca 6y ago
    > Underlying technology aside, mercurial has (I think) quite objectively better cli interface. I disagree. The fact that mercurial relied extensively on extensions to implent basic features, thus exposing a non-standard interface to the world, made it's mental load significantly higher than simply using a standardized (albeit debatable) interface to do standard things. Case in point: requiring installing extensions to stash local changes.
    - throwawayzRUU6f 6y ago
      > relied extensively on extensions to implent basic features Sorry, this is a strawman. Yes, `hg shelve` is a very nice extension. But that's about the only add-on I've ever needed, while working more than 7 years on reasonably complex projects spanning about a dozen teams, in multiple timezones and repositories. And it takes less than 5 minutes to install. We were forced to move to Git after being acquired, and while the migration was painless, the day-to-day friction caused by Git porcelain is notably higher than with Mercurial. The issues caused by line-endings alone waste more time than all the Mercurial issues combined.
      - rualca 6y ago
        > Sorry, this is a strawman. It really isn't,and you cannot hide Mercurial's failings by trying to move the goal post. It's a fact that Mercurial's non-standard interface created a mental load for basic ops that is considerably higher that git's reliable and predictable (and, more importantly, learnable) interface. > Yes, `hg shelve` is a very nice extension. But that's about the only add-on I've ever needed. It's not a "nice extension". It's core functionality, which is a part of any basic introductory workflow. And with mercurial instead of just being able to stash changes with a simple $ git stash , all of a sudden you need to bother with installations and setups and configs and checking if everything is it's place. Just. To. Stash. A. Change. And if you find stashing nothing more than "a nice extension", and nothing else pops into your mind, then you clearly have limited experience in using revision control systems. > And it takes less than 5 minutes to install. Did you failed to notice that it forces you to waste time ensuring you're bolting on all the stuff you need whenever you jump a seat or pop into an instance? And did you failed to realize this problem is not experienced with pretty much any revision control system? Not just git, but pretty much all of them.
- laurencerowe 6y ago
  While Git is conceptually beautiful, it's CLI seems something of an afterthought and is maddeningly inconsistent at times.
- mumblemumble 6y ago
  It's, of course, impossible to do a practical experiment where someone doesn't learn, and therefore become biased toward, one of them first, and then learn the other after. For my part, what I can say is, I used Mercurial for one year, and Git almost exclusively (I do occasionally touch Subversion) for a straight decade after that. And I still find myself having to consult Git's documentation far more often than I ever did with Hg. And, even now, I find myself having to un-pick minor screw-ups in Git more often than I did after only a couple months on Mercurial. I'm pretty sure that the problem here is ultimately the UI and not the data model. No, I'm sure it is. Every time there's a conversation about Mercurial vs Git, and someone says, "Git's not that bad, all you have to do is learn the data model, and then learn all the different ad-hoc ways the UI is bound to it," my immediate thought is, "You see, that's exactly the point. The thing that's nice about Hg is that you don't have to take this extra learning step, because the data model and the UI model are one and the same." Also, merge conflicts seem much more common in Git. I'm not sure if that's a UI problem or a data model problem; I could see it being either or both. In any case, I felt much more comfortable allowing branches to live for days in Hg. In Git, branches that survive past 24 hours seem to always result in either shaving or getting trampled by yaks.
- kelnos 6y ago
  As another data point, I used CVS and later SVN for years before I used git, and I find git to be incredibly easy to use and understand. But I've been using it for over a decade, and spent time in the early days to understand how it works under the hood. This isn't to say git has a good user interface. I don't think it does. I'm comfortable with it because I've spent many years using it, and because I expended extra effort (effort I don't think an average user should have to expend) to learn it well, and to be unafraid of making mistakes while poking around.
lowbloodsugar 6y ago
I know git is confusing on the one hand, and somehow instills over-confidence on the other. But the underlying implementation of "Store everything, SHA it, and build a merkel tree" is, in my opinion, the kind of thoroughness I want in a version control system.
brodie 6y ago
Short of breaking backwards compatibility at this point, there’s nothing preventing Git from being as simple as Mercurial CLI-wise. The two projects are nearly identical on a high level.

DoofusOfDeath 6y ago

I forget - was there another side to the story that made McVoy's actions seem more reasonable? If all I had to go on was Bryan O'Sullivan's email, I'd be tempted to draw some unflattering conclusions about McVoy's conduct.

espadrine 6y ago
Mercurial was officially named after Larry McVoy. (No idea about git.) That said, in his defense, causing the creation of multiple open-source competitors to one’s moneymaker can be stressful.
- ben509 6y ago
  > (No idea about git.) Quoth wikipedia[1]: > "I'm an egotistical bastard, and I name all my projects after myself. First 'Linux', now 'git'." [1]: https://en.wikipedia.org/wiki/Git#Naming https://en.wikipedia.org/wiki/Git#Naming
kelnos 6y ago
I read a lot of the mailing list threads back when all this was going on, and I don't recall feeling any particular sympathy toward McVoy at all. The fundamental issue I saw was that McVoy decided to foist what I consider an unconscionable license agreement upon his unpaid open source users: users were prohibited from working on another version control system without having their license to use the read-only BitKeeper client revoked. (And reverse engineering BK's protocol was also forbidden.) From the starting line I already thought he was slimy for that. This is where Torvalds should have gotten his big honking "I told you so", but I expect he took the wrong lesson from it since he was able to whip up an acceptable alternative in git in a fairly short amount of time[0]. Anyway, McVoy was usually pretty civil in email threads about the whole thing (likely with a few angry words here and there), but I don't think that really mattered to me: IMO he was asking something unethical of his users from the start, and so I think ethically Tridge was completely in the right to reverse engineer BK's protocol and write an unencumbered client. McVoy's response to take his ball and go home was of course entirely within his rights, but was oh so childish. And, surprise, BitKeeper has since failed as a product; I believe it's now open source, and has a tiny fraction of git's user base. [0] I think it's easy for some to take the -- IMO mistaken -- view that "being allowed to" (eye roll) use BitKeeper was a "generous" gift, because it pushed someone to build a viable open-source alternative when their back was against a wall. My view is that it was just lucky for the open source community that McVoy went up against one of the few people with the talent and motivation to out-build BitKeeper. This is one of those times RMS's preaching against using closed-source software is so spot-on, publicly, painfully correct.

mkj 6y ago

Isn't Mercurial different only in nomenclature? The manifest id stored in a changeset is a tree snapshot. Otherwise I don't think hg-git would work as transparently as it usually does. https://www.mercurial-scm.org/wiki/ChangeSet https://www.mercurial-scm.org/wiki/ChangeSet

brodie 6y ago
They’re different in the their implementations of how repositories are stored on disk. Other than that, you’re right in that the two systems have a gigantic (almost one to one) abstract/conceptual overlap.
espadrine 6y ago
They did add it; I think it wasn’t there in v0.1[0]. Nowadays, the revlog contains a sequence of either snapshots or deltas[1], a bit like video codecs I-frame and P-frame, except the heuristic is how much data must be read to check out the file; so most are likely deltas. [0]: https://lore.kernel.org/lkml/42692470.9050605@tmr.com/T/ https://lore.kernel.org/lkml/42692470.9050605@tmr.com/T/ [1]: http://hgbook.red-bean.com/read/behind-the-scenes.html http://hgbook.red-bean.com/read/behind-the-scenes.html