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.

If you autosign every commit then you aren't validating anything anyway. All that means is you have another mindless process running automatically in the background. So what's your point?

You're talking about two different threats / attacks:

1. Someone got access allowing them to push commits.

2. Someone got access allowing them to push commits and also got unrestricted access to the trusted PGP key.

In the first case, auto-signing will expose the issue. In the second, not. But in the second case, you're likely screwed in many other ways.

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.

I was also told that having a signature on every commit makes pulling the entire repo take forever (because it has to validate every commit). Not sure how true that is.

While I don't know how bad the performance would be on huge repos, there is of course an option to turn it on or off (--[no-]verify-signatures.) which I believe is off by default.