And as noted nearly every time this 7-year-old comment by Torvalds is mentioned, this is of course technically correct due to the properties of git's Merkle tree, but completely impractical as far as the human implications.

Consider: You've just written 20 lines of code, and you're creating a commit. Can you validate that all 20 lines were created by you before you commit?

Now, consider that you're looking to create a tag for version 2.0, coming from 1.4, with a net 4,000 new lines of code. Can you quickly and confidently validate that all 4,000 lines of code are as expected?

Clearly, the frequent, small validations are much simpler than infrequently signing huge releases. When integrity matters and humans are involved, small batches win.

Linus has a point, but it's not without flaws. Linus is saying that it makes you complacent, and doesn't prove anything about any release, and that you should sign golden commits. He says this because only what is shipped needs to be trustworthy; and the value of a signature degrades with the more things it signs.

This raises the question, though; how do you know when you reach that golden commit? Is the signer responsible for auditing every commit since the last signature, every line of code? If he doesn't, what does the signature prove?

That's what Linus has wrong; The signatures aren't about proof, they're about audit trail. For Linus and the kernel.org use case, this isn't necessary. They've already built tooling, and most importantly structure around the code auditing. Every commit that goes into the mainline is somewhat audited by Linus himself. There's a whole layer of competent release engineers in front of him. Code doesn't make it onto the kernel.org repos without having been trusted by a very select group, and doesn't get pulled to master without the word of God.

I suggest, for the average developer, having two keys. One online, to verify that the commit was developed on your computer. One offline, that is only used for releases. One for audit trail, one for golden.