this post was submitted on 20 Dec 2023
34 points (97.2% liked)
Git
3718 readers
1 users here now
Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.
Resources
Rules
- Follow programming.dev rules
- Be excellent to each other, no hostility towards users for any reason
- No spam of tools/companies/advertisements. It’s OK to post your own stuff part of the time, but the primary use of the community should not be self-promotion.
Git Logo by Jason Long is licensed under the Creative Commons Attribution 3.0 Unported License.
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
This glosses over what is, to me, the most fascinating part of the history.
SVN was, along with its proprietary contemporaries like Perforce, a pain in the ass as far as branching and merging and collaborative workflow across more that one branch of development or one machine installation. It worked, kind of, but for something at the scale of the Linux kernel it was simply unmanageable. The distributed nature and scale and speed of Linux kernel development, and the cantankerousness of most of the kernel team, meant that they weren't willing or able to put up with any available solution while their project was progressively scaling up. And therefore, the version control system used by the team for one of the most advanced pieces of technology in the world for quite a lot of its development, was... diff and patch. And email. Linus just kept separate directories for separate versions, with the names of the directories corresponding to version numbers, and every single change that needed to go into the kernel would get emailed to Linus (or emailed around developers who were collaborating on "a branch"), and people applied diffs manually in order to pull changes.
That sounds like a joke, but it actually made more sense than anything else they could do. The workflow of a pull request, with no necessity to maintain a shared source repository which was centrally updated, simply didn't exist in any version control system at the time. diff and patch and email could do that, and it was quick and easy for small changes and possible (with some discipline) even for large changes. Everyone sort of knew that it wasn't ideal, but it was literally better than anything else available.
So, bitkeeper. It was a little weird for such an open-source darling to switch to a proprietary VCS, but its creator and CEO Larry McVoy was a respected kernel developer himself, and he was basically offering something for free that would be a significant step forward. Bitkeeper supported a lot of modes of distributed operation that were unique among VCSs at the time, informed by McVoy's own firsthand experience with working on the kernel alongside everyone else, and so it was generally regarded as a step forward technologically. From around 2002 to 2005, the kernel used bitkeeper as its primary source control.
It was a little bit of an uneasy peace, though. Some kernel developers were unhappy with having the source and all revisions "held hostage" within a proprietary VCS, and wanted to have the ability not to use Bitkeeper. McVoy, for his part, didn't do himself any favors by being kind of a pain in the ass at times. A central point of contention was his objection to people "reverse engineering" elements of the BitKeeper protocol. Some developers wanted to be able to interoperate with bk without having to license McVoy's software. McVoy said they weren't allowed to, and said they could have a license to his software for free so what was the big deal. Things came to a head when Andrew Tridgell, a developer who did have access to bk, was accused of "reverse engineering" and had his license (and hence his ability to work) removed. Everyone got mad, arguing about Bitkeeper substantially eclipsed useful work on the kernel, and the need for a better solution could no longer be ignored. (It was later revealed that Tridgell's "reverse engineering" was to access the Bitkeeper endpoint with telnet and type "help".)
Linus, in his inimitable fashion, decided to solve the problem by putting his head down to create the solution and then dictatorially deciding that his solution was going to be the way going forward. It may not be in people's memory now as clearly as it was back then, but he was (and is) a genius wizard-man at systems design and architecture, and obviously his word was basically the word of God on significant matters within the kernel community. Basically, he took a lot of the concepts that made BitKeeper work, and put them within a lot more clean and general architecture, spent a few weeks making a working prototype with a lot of feedback and testing by the kernel team (which by this point absolutely badly needed the whole thing to work just so they could do their day-to-day development again without any fistfights), and then said, we're switching to this, everyone install it and shut up and stop fighting please. Over the succeeding years it was so clearly leaps and bounds ahead of any other VCS that more or less everyone in the world switched to it.
Moral of the story? Let people be. If McVoy had been a little more accommodating, maybe we'd have BitKeeperHub today, and he'd have been able to collect license fees from half the developers on the planet because everyone wanted to use his still-superior-to-everything-that-exists solution.
(edit: Added the details about Andrew Tridgell's reverse engineering)
There also were other distributed VCS around - with arch being available not too long after bitkeeper - but they all typically worked only for some styles of working, and pretty much all of them ran into massive performance issued once the codebasw got large.
Yeah. Seeing the development thought process at work during the engineering of git was really cool. The philosophy was basically, at its core it's not a version control system. It's a content-addressable filesystem. That's what you need in order to build a good distributed version control, so we'll make two layers and make each one individually very good at what it does. Then in a UI sense, the idea was to give you the tools to be able to do needed operations easily, but still expose the underlying stuff if you need direct access to it. And then to optimize the whole thing to within an inch of its life under the types of workloads it'll probably be experiencing when being used as version control.
It was also, as far as I'm aware, the first nontrivial use of something like a blockchain. The property where each commit is referred to by its hash, and the hash encompasses the hash of the previous commit, was a necessary step for security and an obvious-in-retrospect way to identify commits in a unique way.
Basically the combination of innovative design with a bunch of core concepts that weren't really commonly in use at the time, combined with excellent engineering to make it all solid and working well, was pretty mind-blowing to see, and it all came together in just a few weeks and started to get used for real in a big sense. Then, the revolution accomplished, Linus handed git off to someone else and everyone just got back to work on the kernel.
It really was just the (very solid) foundation he knocked out in that time - the ui was horrible back then. Linus just did what was required to get the kernel unstuck.
I started moving the first of my own CVS repos to git in late 2007, and it wasn't ready for the average user at that time yet.
Linus handing it off quickly was the right thing to do, though - otherwise we all might be using something else nowadays, with just the kernel and a handful of projects with similar requirements using it. Many great developers would've wanted to hold on to their baby in that situation, preventing it from growing to its full potential.