<p><pre><code> > What shall we do, then, if we receive a pull request for a
> certain feature or bugfix with, say, 300 commits
> 1. Request that the user squash all the commits into a
> single commit
> 2. Adopt a security policy that requires signing only the
> merge commit (forcing a merge commit to be created with
> --no-ff if needed).
> 3. Sign each commit to be introduced by the merge.
</code></pre>
Or, tell them to rebase their branch on master, while cleaning up all their "oops", "revert", "typo", "debug" and whatnot commits; resulting in a sane history and 20 commits to be signed. I find this oversight especially sarcastic as he mentions how 2. ruins git bisect, while such uncleaned 300 commit branches ruin it just as effectively, as you can never be quite sure whether the commit you arrive at isn't reverted by one 20 commits later and the real issue was introduced another 20 commits later.
To be honest, i feel like git really needs better wrappers or a better GUI or better defaults.
There shouldn't be a quadrillion command flags to know for simple tasks like this. And i don't mean the -S but the "use -S instead of -s but for other things use -asm, oh and then you have command xyz which takes --<long option> followed by other options, but only use those if your SHA hash can be divided by 3.141 and it's full moon".
Discussion from 2 years ago:<p><a href="https://news.ycombinator.com/item?id=4007229" rel="nofollow">https://news.ycombinator.com/item?id=4007229</a>
You're supposed to sign a tag because you've reviewed that tag, not just at random. A commit is much less meaningful - do you always check the diff before you commit?