Hacker News Reader

Comment by espadrine | Hacker News Reader

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

View on HN

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.

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

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.

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

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

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

While Git is conceptually beautiful, it's CLI seems something of an afterthought and is maddeningly inconsistent at times.

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.

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.

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.

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.

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

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.

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/

[1]: http://hgbook.red-bean.com/read/behind-the-scenes.html

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.

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.

> (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

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.

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

I'm letting you use my commercial product under the understanding that you won't try to undermine it... I think that's actually pretty reasonable. I'm giving you something for nothing in return, and all I ask is not to try to take more from me? I always though that Tridge was ungrateful in the situation.

I get that you might have no problem with that, but personally I find that kind of arrangement unethical, and I would never agree to that sort of license.

Also note that I believe the "free for open source users" version of the BK client was a read-only client that only allowed pulling code. So it's not like McVoy was giving his whole product away for free, out of the generosity of his heart.

> ...and all I ask is not to try to take more from me?

Reverse engineering is a neutral activity. There's no "taking" going on.

> I always though that Tridge was ungrateful in the situation.

Ungrateful that he was forced to use a crippled, proprietary tool to interface with the development process of a project he's involved in? A tool that expressly disallows him from doing anything to make that situation better? That's rubbish.

This is where Torvalds should have gotten his big honking "I told you so", but I expect he took the wrong lesson from it

which lesson did he take and what should he have learned instead?

What I think he should have learned: betting the workflow of your open source project on a closed source solution is going to come back to bite you, and you shouldn't do that in the first place.

What he probably learned: I'm badass enough to clone a proprietary tool in a matter of weeks if my decisions end up being bad.

Which I guess is fine for him, but likely not most people.

Reply on news.ycombinator.com