Emphatic agreement, this is something I've wanted for a while. For the purpose of history management/traversal (reverting, bisecting, or just understanding) you want certain code changes to be atomic, implying that they should all be understood/tested/reverted together. But for the purpose of code review you want something more granular and less monolithic, so that a single reviewer can more easily understand a large change, or so that review can be more easily divvied out among certain code owners. Currently getting all all of these properties requires decomposing the commits during the review phase and then squashing before merge, but this is a bad practice because now no reviewer has actually signed off on the code that's getting merged and you're just hoping that nobody's slipping any last-minute or malicious changes in during the squash.
Agreed; however, since this is HN, I'd like to suggest that it should be totally doable to improve on the squashing workflow using tooling. Programmatically it's easy to verify that the signed-off commits induce the same diff as the squashed commit; they're either equal or not. Then, if the interface where signoffs are registered (e.g. github PR) enforces that all PR's are signed off while allowing a squashed, un-signed-off commit if it has the same diff as a signed-off commit, then you can squash at will. Optionally you could also require that the signers additionally sign-off the final commit, under the tool-provided guarantee that the diff is identical.
