Slashdot Mirror
10 Years of Git: An Interview With Linus Torvalds
LibbyMC writes Git will celebrate its 10-year anniversary tomorrow. To celebrate this milestone, Linus shares the behind-the-scenes story of Git and tells us what he thinks of the project and its impact on software development. From the article: "Ten years ago this week, the Linux kernel community faced a daunting challenge: They could no longer use their revision control system BitKeeper and no other Software Configuration Management (SCMs) met their needs for a distributed system. Linus Torvalds, the creator of Linux, took the challenge into his own hands and disappeared over the weekend to emerge the following week with Git. Today Git is used for thousands of projects and has ushered in a new level of social coding among programmers."
It isn't complicated. Check out Git - The Simple Guide.
As a software developer who's been a git user for 7 years, I don't know how I could have written any serious code without git. Branching and merging is trivial. Cloning is trivial. The staging area makes choosing what to commit trivial. git rebase makes life much easier when it comes to reordering/editing/removing commits out of the history. git blame --- such a nice tool. Binary searching to find bugs is trivial. Every git tool is documented to within an inch of its life.
And the icing on the cake? Code cowboy hates git. Like sunlight or garlic to a vampire, Code cowboy abhors git. He can't hold the source code hostage to his every brain damaged whim. He can't hose anybody with a distributed version control system. It's no wonder why Code Cowboy is always yapping away at git -- he can't show off his genius if his code can be ignored.
how bitkeeper fucked up and was swiftly relegated to irrelevance... you have to wonder how many of these are even still using bk......
You have to understand the data-structure, how files, directories and commits are all content-addressable objects. The linkage of the commits by means of their id's must be understood.
Git: the best file system anybody ever confused with a version control system. :-)
You have to understand the data-structure, how files, directories and commits are all content-addressable objects. The linkage of the commits by means of their id's must be understood.
See, here's the thing. Why should I have to understand internal data structures in order to use a piece of software? Imagine if you made a word processor and people found it difficult to understand, and you said, "It's easy once you understand that the words in the text are stored in a hash map along with a structure with various flags that encode things like whether it's italic or not." People would look at you funny and go back to using Word.
I worked for used git for their SCM and I asked where the backups were I was told they didn't need backups because it was distributed and everyone had a copy of the repo
This is only tangentially-related, but a good story, and it's been a few years since I posted it.
About 20 years ago, I worked for a company which I shall not name, which used CVS as its source repository. All of the developers' home directories were NFS mounted from a central Network Appliance shared storage (Network Appliance was the manufacturer of the NAS device), so everyone worked in and built on that one central storage pool. The CVS repository also lived in that same pool. Surprisingly, this actually worked pretty well, performance-wise.
One of the big advantages touted for this approach was that it meant that there was a single storage system to back up. Backing up the NA device automatically got all of the devs' machines and a bunch more. Cool... as long as it gets done.
One day, the NA disk crashed. I don't know if it was a RAID or what, but whatever the case, it was gone. CVS repo gone. Every single one of 50+ developers' home directories, including their current checkouts of the codebase, gone. Probably 500 person-years of work, gone.
Backups to the rescue! Oops. It turns out that the sysadmin had never tested the backups. His backup script hadn't had permission to recurse into all of the developers' home directories, or into the CVS repo, and had simply skipped everything it couldn't read. 500 person-years of work, really gone.
Almost.
Luckily, we had a major client running an installation of our hardware and software that was an order of magnitude bigger and more complex than any other client. To support this big client, we constantly kept one or two developers on site at their facility on the other side of the country. So those developers could work and debug problems, they had one of our workstations on-site, and of course *that* workstation used local disk. The code on that machine was about a week old, and it was only the tip of the tree, since CVS doesn't keep a local copy of the history, only a single checked-out working tree.
But although we lost the entire history, including all previous tagged releases (there were snapshots of the releases of course... but they were all on the NA box), at least we had an only slightly outdated version of the current source code. The code was imported into a new CVS repo, and we got back to work.
In case you're wondering about the hapless sysadmin, no he wasn't fired. That week. He was given a couple of weeks to get the system back up and running, with good backups. He was called on the carpet and swore on his mother's grave to the CEO that the backups were working. The next day, my boss deleted a file from his home directory and then asked the sysadmin to recover it from backup. The sysadmin was escorted from the building two minutes after he reported that he was unable to recover the file.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.