At a previous company, there was an “infamous” commit in our main repository. The commit was about 10 years old, and it replaced every tab with 4

When it comes to git history, less is more

submited by

Style Pass

2021-06-16 09:00:19

At a previous company, there was an “infamous” commit in our main repository. The commit was about 10 years old, and it replaced every tab with 4 spaces. When the commit was authored, the repository was likely in the hundreds of thousands, or maybe millions, of lines of code. For folks like me, who liked to go “spelunking” through git history, it was a frustrating barrier, but no more than a moderate frustration. It didn’t impact day-to-day work. After all, this repo was a regularly-deployed web application. Development happened on the master branch, deploys happened multiple times per business day, and old revisions were quickly forgotten.

When I started trying to contribute to the Linux kernel, the commonly suggested way to get started was to contribute coding style fixes, or to correct simple warnings from a static analyzer. But this came with some advice: try to keep your submissions within the drivers/staging directory, because many core kernel subsystem maintainers and reviewers don’t appreciate those trivial patches. I remember being quite frustrated at that. It felt quite unwelcoming to be restricted to what I saw as a “playground”, rather than working on “real kernel code.”

Now, my day-to-day work involves diagnosing, reproducing, and fixing bugs in Linux kernel versions which have been released for years. Unlike a web app, the kernel has long-term stable releases that continue to be supported long after the master branch has moved on. Fixing a bug on the master branch doesn’t magically fix all those released kernels; instead the fix must be backported to each older release.