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."
Very few people actually know their version control software. Most people know the basic commands, and that's the case for pretty much all of them. Git is not much different in that regard.
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.
As someone mostly in the "I dun get it" crowd, I'll say the problem for me is that I feel like while I can use it, I don't have a great deal of understanding as to what it's actually doing outside of the basics. I feel like I'm following a bunch of recipes that I know work.
With svn (which admittedly I've used for many years and on sizable projects vs git which I've used for months and on small stuff), I feel like I have a really good grasp of the whole thing. Sure there are some subtle bits I don't know because I've never needed, but I know the important bits, and I feel like from that I can solve just about any problem I run into by understanding what svn is trying to do and why it's not working.
I get that at least some of this is just inexperience, but I think even with experience, git seems far more complex and nuanced than svn, which has a relatively consistent way of working and a seems to have a much smaller set of features. I feel like I got comfortable with svn way faster, and at that point I was only mildly familiar with version control in general.
I know I'm gonna get flamed for this, but just wanted to provide some insight into the mind of someone who hasn't jumped on the git bandwagon yet.
I hear from so many people who love git, and also from so many people who see it as needlessly complicated to the point of getting in the way of getting things done. If that latter view didn't have any truth to it, this page wouldn't exist:
http://git-man-page-generator.lokaltog.net/
So, which is it? A useful tool, or simply a way for the the brightest technology people to feel smarter than everyone?
Personally, I'm in both camps. I both hate and love Git. I hate that I have to explain and provide "scripts" to developers that explain how the project uses Git and I love that I can manage my project in multiple ways, depending on my needs.
Git's problems stem from it's Unix like command line basic user interface. It's not a surprise that they decided to go with this kind of interface, they where basically Linux developers after all. In the tradition of good CLI's, Git is full featured, meaning it does a LOT of things, or really it supports doing things in a lot of different ways. I love the flexibility. But, unless you understand what Git is doing for you under the covers you may not know which of the confusing commands in Git you need to use. If you don't understand how your project is using Git, it may be difficult for the newbie come up with the necessary commands to get things done.
Personally, I end up writing scripts for my developers. I force them into following a set procedure to "check out" the source, do their local development and get their changes though the review cycles and into the main repository again. Developers don't like scripts like this and because it's a script that describes how they use git, they think they don't like git. What they really hate is being told exactly what to do...
I love git because it allows me to control my project's source. It keeps local backups and my history on MY machine, but doesn't expose others to my mindless rambling commits unless I decide to push them. I love the flexibility to manage my source how I want too locally....
So, IMHO, git is great and a curse at the same time. Much like AWK and SED where a huge boost to the Unix CLI (if you understand them) git is wonderfully complex and thus frustrating to learn. Git doesn't force you into a configuration management model, but lets you roll your own process. Being flexible is great but git doesn't stop you from shooting yourself in the foot so be careful and know how you want to manage your repo, figure out how to make git do that, document how it's done, and test your process.
Remember, it's the PROCESS you need to have straight in your head. Just googling Git is going to cause you trouble because how THEY use git is unlikely to match how YOU want to use it. You got to know your tools and git is no exception but you REALLY need to know what you are trying to do with git.
"File to fit, pound to insert, paint to match" - Aircraft Maintenance 101
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.