Glad You're Ready. Let's Get Started!

Let us know how we can contact you.

Thank you!

We'll respond shortly.

Thoughts on Linus Torvalds’s Git Talk

At Pivotal Labs last week we watched Linus Torvald’s Google talk about Git, the Source Code Management (SCM) system he wrote and uses to manage the Linux kernel code.

I’ve watched it twice now and here are some thoughts, based on quotes and themes from the video.

“I Never Care About Just One File”

Linus stated that one of the reasons Git was wonderful for him is that, as a high level code maintainer, he needs to merge thousands of files at once. In fact, he stated that he never cares about just one file.

Not so for me. As an in-the-trenches developer, my whole life is caring about just one file, over and over again. When I merge, I care about each file because, since I work on small teams and with small codebases, there is a fairly high likelihood that my changes will collide with those from another developer.

“The Repository Must Be Decentralized…. You Must Have a Network of Trust”

Linus made the point that central repositories suck for large projects where the morons must not have commit access — only the super privileged are allowed to commit code back to the repo. He argues that Git is better because it is a decentralized network of repositories — there is no central master, only Some Dudes who have repositories. Usually there is Some Dude In Charge, like Linus, and everyone tends to pull code from them. To update the “master” code version, Some Dude In Charge pulls code from the repositories owned by Some Other Wicked Smart Dudes, who have most likely pulled code from Some Other Trusted Dudes (And One Gal), and so on. Thus, rather than limit access to just the hand-selected few, everyone has their own local copy of the repository, and the smart merge from the smart who merge from the smart, resulting in some kind of official or de facto version.

While I like the local copy of the repo idea, Pivotal does not work the way Linus describes… but Pivotal is weird, in a good way. We all have full commit rights. Our network of trust is everyone. The Dude In Charge is named Continuous Integration. CI makes the official versions. CI runs the tests. CI makes sure that the deploy process works. I’m sure that we could coerce Git into working in a centralized-like way, where it merges automatically from the individual developers and runs the builds, but I’m not sure if that would be forcing a square peg into a penguin-shaped hole.

“Some Companies Use Git And Don’t Even Know It”

Linus described how developers at some companies use Git on their development machines, committing their changes and merging fellow developer’s changes with Git, then pushing those changes to central SVN repos. He rather mocked this, but it actually sounds like a good solution: developers merge, so use the tool that’s good at that. CI machines and deploy machines love centralized master repositories, so use that for those jobs.

“It Does Not Matter How Easy It Is To Branch, Only How Easy It Is to Merge”

Well said. I never thought about that before but he is completely right. I could never put my finger on why I never branch in SVN, even though it’s practically ‘free’ and easy to do. Now it’s obvious: who cares how easy it is to branch when merging sucks? Git is supposed to make merging incredibly easy because Git is content-aware rather than just file-aware… or something like that. I’ll believe it when I see it, but if Git really does make merging highly divergent branches easy then I’ll give it a try.

Joe’s Take

I’d like to try Git, especially if it makes branching and merging those branches as easy as Linus suggests, but I don’t think that Pivotal would get as much benefit out of it as large, distributed open source projects. A ‘really big’ project might have 10 developers, not thousands, and all must have commit rights. Our network of trust goes like this: if you are here, we trust you; if we don’t trust you, you have to leave. And the idea of having to merge directly from my fellow developers sounds like a pain in the ass… why would I want to merge from 3 separate pairs when I can pull code from the central repo and be reasonably sure (thanks to CI) that it is clean and green? Hopefully I’ll be able to answer those questions soon by using Git on a project.

(Note: originally posted on my personal blog at

  1. Alex Chaffee says:

    Git outta here!

  2. Tim Connor says:

    I’m still using svk with our svn at work (which might be a lower adaption pain threshold than gitting svn) and I highly recommend giving something with pain-free merging a try. It makes you much more likely to branch properly, lets you stage your commits better, and makes it easy to switch back and forth to a quick fix mid-stream, even if you have a big change pending.

    Also, no reason you can’t run a central repo with git. Have everyone just pull from the same master on your CI box, and wallah, more centralized svn like workflow, with the advantages of git. Also, then you don’t have to deal with trying to get your repo back up from backups, or having one of the developers secretly using svk/git push it back up to a bare repo, when it inevitably gets wedged (which svn will do). Instead, just declare someone else’s repo as MCP while whatever went wrong with the CI machine is fixed.

    And if you got good with git, it’d work for shooting pre-pushed changes in need of review, around, and similar more flexible SCM-usage. Of course, all of this could be done from a central svn repo, but then you are counting on the bridging libraries, and there is no reason git cannot work centralized. Of course, if you are really wedded to Track…

  3. Pat Maddox says:

    Well I definitely wouldn’t write it off before actually using it, if I were you :)

    Regarding not caring about one file, I think you might be a little too focused on that one sentence. You actually got to the point later in the post, which is that one of git’s huge advantages is that it tracks content vs files. Put another way, files are just abstractions for organizing our code, and they should be easy to refactor. This is one of git’s central principles, and one that subversion doesn’t share.

    I’ve actually always used a central git repo, precisely for the reasons you mentioned. It’s useful, particularly when using CI, to have one “master” repo. Developers just push code to that whenever they want, just as you currently do with svn. The difference is that developers can easily branch and merge locally, trying all kinds of crazy experiments, sharing half-baked patches with other devs, etc. The end result is more collaboration, and ultimately higher quality code going into the master repo because it’s had more opportunities for review and testing.

  4. Chris Bailey says:

    I haven’t listened to the talk, but your comments seem right on. I do agree that SVN sucks for branching and merging, at least after having used Perforce. I used to work at Adobe, who uses Perforce for everything, and in an environment like that (not all that unlike yours), we made *extensive* use of branches, in fact, on many codebases, everyone was simply required to work in a “sandbox” (branch). It worked extremely well, and I don’t like working any other way, but with SVN it’s not nearly as pleasant. Perforce made merging back in pretty much trivial. SVN sucks at it.

    However, I’ve started using, which sets up merge tracking in the SVN repo, and it actually seems to make things a lot nicer. I’ve run into a few issues once in a while, but so far it’s a HUGE improvement when say working in a sandbox/branch type environment (one of the projects I work on requires in, and we use SVN, so this was a nice help).

Post a Comment

Your Information (Name required. Email address will not be displayed with comment.)

* Copy This Password *

* Type Or Paste Password Here *