Musings on Git

Having spent some quality time with Git over the holidays, my appreciation for the flexibility of this DVCS and the elegance with which it has been constructed has reached a state of awe. I remember following the BitKeeper debacle of 2005 on Kernel Traffic that spawned the project that would turn out to be git, and wondering why Linus would even think of going off on a tangent and building a VCS. I’m thankful that he did.

In a mail to the LKML, Linus mentions:

So I’m writing some scripts to try to track things a whole lot faster. Initial indications are that I should be able to do it almost as quickly as I can just apply the patch, but quite frankly, I’m at most half done, and if I hit a snag maybe that’s not true at all. Anyway, the reason I can do it quickly is that my scripts will not be an SCM, they’ll be a very specific “log Linus’ state” kind of thing. That will make the linear patch merge a lot more time-efficient, and thus possible.

What I find interesting is his statement that “my scripts will not be an SCM” sounds a lot like “won’t be big and professional like gnu” in an earlier mail to a different crowd. Pay attention when hackers sound humble and self deprecating. It’ll be easy to spot, since they’re not most of the time. I kid, of course.

Having hacked on Linux for a long time, I believe Linus really enjoyed taking a break and doing something different, and in this talk, it’s clear that he was quite proud of his creation. It’s also very clear that the entire system was thought up by a kernel hacker from the focus on making the system fast and efficient, not to mention being able to do a “fsck” on the git repository also shows which analogies were drawn in designing git.

Managing kernel contribution is a difficult process, and with over 1000 contributors to each kernel release makes it one of the most prolific open source projects in history. The benevolent dictator and the governance structure that he’s laid out for the kernel over the years seems to be able to manage this complexity and scale efficiently. Git has played a major part of this success and I expect will continue to do so in the coming years.



Quilt is a great tool to maintain patchsets.

For those new to quilt, let me brief you on how it works.

If you take something like the kernel sources, you would eventually need to apply patches to give it functionality that has not made it to the official tree. Examples like suspend2, xen, bootsplash, drivers and all that other kernel goodness floating around. Sometimes different patchsets need to be applied and different branches of the source tree will need to be maintained. When applying patches manually, no record of the patches is kept (apart from the actual changes themselves) so its difficult to say which patches have been applied. Reverting patches can be tricky if they’re order dependent.

Here’s how you would use quilt to simplify this madness.

Simply make a patches/ directory inside your kernel source tree, and dump all your patches in it. Create a patches/series file and list all your patches in the order that it should be applied. Once you’re done, back from the root of the kernel source tree, type ‘quilt push -a‘. If everything applies cleanly you’re good to go. To see which patches have been applied ‘quilt applied‘. To revert the last patch, ‘quilt pop‘. To revert everything ‘quilt pop -a‘. It’s really that simple. Quilt takes a stack oriented approach to patching which is extremely intuitive.

The patches can be kept elsewhere and symlinked from within the patches folder. That way you can maintain multiple kernel trees with different patchsets and a common repository with all your patches for easy maintenance.

Oh and updating a patch is a simple ‘quilt refresh‘.

Happy patchin’.

Messing with the Colonel

I’ve been reading Linux Kernel Development by Robert Love recently, and it’s exactly the book I’ve always been looking for. A number of kernel books have spent a long time in my wait queue gathering dust and becoming obsolete with every passing day. I’ve gazed longingly at the venerable Lion’s Book on many many occasions only to push it back in the queue because I felt I needed to finish another book first before I could move on to it.

I put an end to all the procrastination and dived into RML’s book and it was glorious. Seriously folks, five stars. It dives straight into the key aspects of the kernel with code commentary and examples. It doesn’t attempt to present all the details of the various interfaces and subsystems that it covers and leaves that as an excercise to the reader. Armed with something like LXR, this has never been easier.

Also, for those aspiring to mess around with the internals while at it, do check out UML (User Mode Linux) which is already in mainline 2.6 and excellent for creating sandboxes to play with.