> 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 t

> 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. 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.