A Git Origin Story (2018)
linuxjournal.com
linuxjournal.com
It also seems unlikely that that was where it stopped, as that likely wouldn't have gotten any attention. The whole claim just seems disingenuous.
One can be fulfilling one's curiosity in simple and obvious ways and still be breaking license terms or the law. That something is trivial doesn't mean that it is moral, legal or licensed.
In good news, the supreme court clarified/limited the CFAA in June 2021 [1], so it's now seemingly legal to access a server however you like as long as you're not accessing information you wouldn't otherwise have access to.
[1] https://www.theverge.com/2021/6/5/22491859/supreme-court-van...
That would be surprising to me. Being a DCVS, lots of folks in the community would be running their own servers and sharing the URLs to them; that is were Andrew would have noticed URLs like bk://thunk.org:5000. For instance, here's one such URL being shared on the LKML where Andrew hung out: https://www.cs.helsinki.fi/linux/linux-kernel/2003-12/1108.h... It is my assumption that bk.arm.linux.org.ku was not owned BitMover.
Perhaps that means that whoever was running the server than Andrew connected to was in violation of their license by "authorizing" Andrew's access.
Note that the CFAA is a criminal law, so it was possible for Andrew to be prosecuted for breaking it, given a report to the police, if he hadn't been given direct permission to access that server in that way, whether or not the server owner minded.
"It was not, he says, an act of wizardly reverse engineering."
The word "wizardly" is important here. He's denying reverse engineering, only that the reverse engineering wasn't "wizardly," or basically anything magical or special. Just plain old curiosity.
Basically, the browser version of view source.
Larry McVoy basically forced the creation of Git via Andrew Tridgell and look where we are today - while world uses Git. Larry must have had his reasons but I wonder how he feels about the outcome.
In the world of infrastructure software, you have to keep moving forward because open source will replace your proprietary infrastructure software eventually. Stay still, milk that cow, and you'll lose the cow.
It's that simple.
Or better yet: develop a solid open source monetization plan to begin with. Not that that's easy! But D. Richard Hipp managed.
Thinking about it, why couldn't BK have been the SQLite3 of DVCS? The answer is probably that McVoy didn't think about the SQLite model, probably because SQLite was the first to succeed at it, and that came after the BK->Git migration, or at least the realization that SQLite had a great business model came later.
To recap, the SQLite model is this: a) make a great open source project, b) make a proprietary test suite for it with 100% branch coverage, c) convince the world that (b) exists, d) let them come to you for features and bug fixes, e) form a consortium to get paid through. BK coulda been a contendah!
Where does this recap come from?
My understanding was that SQLite was initially created in a context for a client that needed assurances of correctness, thus the extensive testing suite.
As for the revenue, there's a proprietary extension to support fully encrypted db and access. This is licensed and supported.
Is it not true?
> My understanding was that SQLite was initially created...
Ah, you think I meant that that was the SQLite model on day 1. But no, I meant that this is what it became.
> As for the revenue, there's a proprietary extension to support fully encrypted db and access. This is licensed and supported.
Consortium membership costs money. That money pays for the dev team.
https://news.ycombinator.com/item?id=26204218#26205688 (2021)
Some speculation, but is there a chance that Tridgell was aware of MyVoy's condition on the use of BitKeeper as source control for the Linux Kernel and attempted the reverse-engineering deliberately to force the scenario where the development of an Open Source BitKeeper alternative was necessary?
There's a old low-res video (https://www.youtube.com/watch?v=NARcsoPp4F8) of it in action.
I really liked Mercurial and used BitBucket for a while, but in the end GitHub won out.
1. It wasn't developed by Atlassian, who at the time had a reputation for building more unwieldy tools (Jira, anyone?) and had a weird, awkward feel. The fact that Git had gained near instantaneous traction and Bitbucket needed you to learn Mercurial made it a near non-starter.
2. GitHub's model ("Social Coding") and zero-effort force amplification made it just the right wedge. Git had terrible tooling on the frontend and GitHub providing "Just enough" tooling around the server side while also providing the right kinds of tooling (webhooks, enterprise-ish features, click-to-fork, a very good PR path, etc) made it easy to use Git.
Mercurial might be the "superior" tool from certain standpoints but Git had a few tricks up its sleeve that made people like it:
* Written in C. No extra runtimes.
* Modular construction: `git-slap` is immediately available as `git slap` like a native tool.
* Performance of Mercurial was bad on massive codebases and slower machines. I mean terrible. once you hit 500KLOC or into the 2MLOC, a simple merge could take minutes if not tens of minutes in the old days if you weren't on a fairly modern (2005-7ish) machine. If you'd kept your slightly older P2 laptop around, you were absolutely roasting under the weight of what took Git mere seconds.
Could you provide citations or evidence to such a claim? In following HN guidelines, I did not do a quick dismissal. I spent time and ran tests. I do not see the same conclusions. I am ready to post up some data in good faith.
> I spent time and ran tests.
Ok? Share 'em. The scale I'm talking about is ginormous though. (Roughly: multiple GBs, 100k+ files & probably 250k+ commits in history).
For all I know it could be state-of-the-art performance for the scale, but repeat tasks taking minutes is still bad news.
SQLite has their own SCM (fossil), which hasn't taken off to nearly the same degree. Some of it has to do with the main problems different projects have. Some of it has to do with marketshare, and git started on 2nd base in that area.
It’s also true that Fossil (or any of the DVCSs released after Git) might’ve won if only they had released before Git. Fossil was released after Git was, and after Git’s popularity had started growing. I have the impression that Fossil was built partly as a reaction to Git since the Fossil docs have always compared themselves to Git and complained about certain Git features. Fossil historically might not even exist without Git, but either way, market share may not be the primary reason, since one of these two actually predates the other. BitKeeper previously had the market share that Git took over, and BK didn’t win either, so market share may not be the explanation at all. Other reasons for nothing yet overtaking Git may be that nothing yet is better enough. I’d be surprised if something doesn’t replace Git eventually though.
I think it won because VCS transitions are very painful so people wanted to use the system that they expected to end up being most widely adopted. Certainly that's why I chose it in 2007.
And of course when you're making this decision you should assume that many other people are making it on the same grounds.
I believe the term for this situation is a "Keynesian beauty contest".
Git seems a very pure example of the Unix philosophy "worse is better". Lots of evidence that Linus examined darcs in some detail, decided it was "too smart" and wanted/needed "dumb but fast". It's even in the name of git given "git" is a British colloquialism for "idiot" or "fool". Sometimes you just need the dumb tool that works fast and gets out of the way, and the technically better and smarter (but slower; harder to understand) tool loses.
Nothing wrong with that. Yes, there's warts left over all over the place. So what.
It's also useful to remember that git started out dumb and is still dumb in its own ways, because that gives us room to grow, things to aspire to, and areas to continue to research, better "technical" tools to keep an eye on.
Git was named dumb especially with respect to darcs, and from that perspective git will always be dumb: you call git's internals "right", but "right" has multiple meanings. Yes, they are well suited to the job. But the darcs perspective here is that they aren't the most "technically right". Darcs internals use primitives that much more closer resemble OTs/CRDTs. There's a lot of HN love for the technical beauty of tools like CRDTs. Darcs made the case from its beginning that source control and the mental model of source control is much closer to things like CRDTs (keeping in mind darcs predated/coincided much CRDT development) than it is to "trees of trees of files" like it is in git internals. Darcs is closer to the "right" tech internally, especially where its primitives do model programmer behavior better.
It's useful to still have darcs to compare to for what a "smarter git" could look like, even/especially at the internal primitives level. It's useful that projects like pijul are still exploring those ideas even despite "git has won" and "worse is better".
At this point like most everyone, I use git because it is incredibly pragmatic. I appreciate knowing that git isn't perfect, isn't "technically smart", and that there are cases to continue learning how we do the beautiful technically smart stuff in a way that is also or at least nearly as pragmatic.
You grab git, clone stuff, branch out, merge in .. it was transparent locally or networked.. plug and play.
It would be much easier to displace if a huge part of the world's code hosting infrastructure wasn't using it.
Nearly every project will use GitHub, directly or indirectly.
Of course, being a one hit wonder in software is pretty good if your hit is the Linux kernel.
[1] https://en.wikipedia.org/wiki/Subsurface_(software) which is just an alias for Torvald's page, search for "late 2011"
(a) means that, for example, the Windows source code can never fit in a Fossil repository. The issue is that the SQL metadata alone is daunting. Git devs have developed a bunch of techniques for dealing with this, such as shallow clones, partial clones, and the use of Bloom filters for speeding up git log traversal (for, e.g., `git blame`).
(b) is just terribly obnoxious. Rebase == script around cherry-pick. Fossil provides cherry-picking. Fossil refuses to provide rebase. Mercurial too went through the same opinionated stage and then landed at providing all the things that Git power users want. Until Fossil improves this, for example, I can't be bothered to use it much. Why would you reject a huge portion of your audience, especially power users who can influence projects to choose your DVCS?
The world would be a different place. It would be better, though I don't know how much better.
But considering how many times we have heard the "I can build this in a weekend of coding" trope, git is truly an exception weekend-project (+) that actually delivered on the promise.
(+) - Taking vast liberties by stretching the weekend
E.g. to do something like git you'd save a whole lot of effort the moment you know to consider a hierarchical store addressed by hash of contents from the whole repository down to individual files, and a list of the hash of the root of each revision (this description is already a refinement of the first iteration of how git stores trees, which apparently didn't use a hierarchical structure at first but just a list of files according to [1]).
[1] https://utcc.utoronto.ca/~cks/space/blog/tech/GitTreeEvoluti...
A bold claim, but what exactly are these techniques?
That i think is unfair, it's the most prominent, but i would argue that GNU especially GCC was more important. However the way Linus split the work and with that idea used Bitkeeper and then later created Git was revolutionary.
Some opensource kernel's already existed at that time, for example Mach and BSD (to name a micro and monolith).
EDIT: But yeah we all know why BSD was legally problematic around the 90's.
But I think a more important reason for him was that he felt that CVS and SVN implicitly came with a development model where a small group of people has official commit privileges, while he very strongly wants a model without that.
See for example what he says here: https://www.tag1consulting.com/blog/interview-linus-torvalds... (search for "commit bit").
I remember projects where out of 50 people only 1-2 were capable and trusted to do merges. And that was a tedious and boring job so the joke was that you never wanted anyone to know you could merge a code base for release.
Arguably git doesn't like it much as well, but it can branch easier.
The real thing needed was the decentralization, CVS/SVN weren't setup to allow every copy to be a master copy on equal footing (and even now most people do NOT use git that way, they setup main or master and let GitHub be the central authority).
It's possible to only commit part of a merge.
It's possible to accidentally include additional changes after a merge.