Thorsten Leemhuis (acct. 1/4) on Nostr: I liked "The #Git Commands I Run Before Reading Any Code" post[1], but during the ...
I liked "The #Git Commands I Run Before Reading Any Code" post[1], but during the part that contains "Reverts every couple of weeks means the team doesn’t trust its deploy process. They’re evidence of a deeper issue: […]" something in me yelled: "This is more nuanced, and people will be drawing the wrong conclusions if they believe this blindly".
Because for the #Linux #kernel reverts often are a good thing for two entangled reasons:
* No "deploy process" can prevent all bugs, so some will only be found in the wild. This, sadly, is especially true for the #LinuxKernel, as its mostly drivers which are impossible to test properly in a deploy process; the hardware they support furthermore is messy and full of hidden bugs innocent changes can suddenly expose.
* A quick revert can be the fastest way to ensure that mainline usually remains usable and is tested by people, as "fixing a bug through a follow-up commit" often takes more time than "reverting and reapplying later with the bug fixed"[2].
[1] From Alex Piechowski:
https://piechowski.io/post/git-commands-before-reading-code/[2] Can also be better in case people have to use "git bisect" later for other reasons, as the bug then won't interfere while in the range where it's not yet resolved.
Published at
2026-04-09 09:39:49 UTCEvent JSON
{
"id": "80702cbb9b25af8c5ddbd1d5f633053825340377d65ee3efc665e30934c0f3ed",
"pubkey": "f8f4fe83e020824e25b3effd9a69f8268654b25205d6a385090ed4c7ce5c5c92",
"created_at": 1775727589,
"kind": 1,
"tags": [
[
"t",
"git"
],
[
"t",
"linux"
],
[
"t",
"kernel"
],
[
"t",
"linuxkernel"
],
[
"imeta",
"url https://media.hachyderm.io/media_attachments/files/116/374/001/306/662/140/original/47d6ddc72b2b94c1.png",
"m image/png",
"dim 869x496",
"blurhash UD6I5Bs.WXkDjXj?f6ayMakDjYadtTbIj[kC"
],
[
"proxy",
"https://hachyderm.io/users/kernellogger/statuses/116374083334503805",
"activitypub"
],
[
"client",
"Mostr",
"31990:6be38f8c63df7dbf84db7ec4a6e6fbbd8d19dca3b980efad18585c46f04b26f9:mostr",
"wss://relay.ditto.pub"
]
],
"content": "I liked \"The #Git Commands I Run Before Reading Any Code\" post[1], but during the part that contains \"Reverts every couple of weeks means the team doesn’t trust its deploy process. They’re evidence of a deeper issue: […]\" something in me yelled: \"This is more nuanced, and people will be drawing the wrong conclusions if they believe this blindly\".\n\nBecause for the #Linux #kernel reverts often are a good thing for two entangled reasons: \n\n* No \"deploy process\" can prevent all bugs, so some will only be found in the wild. This, sadly, is especially true for the #LinuxKernel, as its mostly drivers which are impossible to test properly in a deploy process; the hardware they support furthermore is messy and full of hidden bugs innocent changes can suddenly expose. \n\n* A quick revert can be the fastest way to ensure that mainline usually remains usable and is tested by people, as \"fixing a bug through a follow-up commit\" often takes more time than \"reverting and reapplying later with the bug fixed\"[2]. \n\n[1] From Alex Piechowski: https://piechowski.io/post/git-commands-before-reading-code/\n\n[2] Can also be better in case people have to use \"git bisect\" later for other reasons, as the bug then won't interfere while in the range where it's not yet resolved.\n\nhttps://media.hachyderm.io/media_attachments/files/116/374/001/306/662/140/original/47d6ddc72b2b94c1.png",
"sig": "a51ce54cc0e725705f55b0762783d66196ddd88931d9e262abf7104d6f63e4931058bffc49e270d4c56f43725b0ba801174d786eeb03a825545981aaea697997"
}
