I generally use autosquash when a code review of a PR turns up things I missed, which should have been part of a particular commit on that PR's branch. However, I don't want to amend the previous commit right away if I'd like another review for the new changes. Thus, I do a `git commit --fixup <HEAD|hash>` and push it. I can then ask the review to only look at the new commit, I won't break their local checkouts of the branch, and only when everything's been approved I run `git rebase --autosquash` and then merge it in.

(Before I started using autosquash for this, I'd do the same, except I had to figure out at the time of merging onto which commit every new commit had to be fixed up, rather than at the time of writing it.)

Thanks for the tip!

I rely on code review tools that can show me the difference between two patch sets. I really love Phabricator for that ability - push a set of commits and each gets a review. Absorb any fixes, push and suddenly each commit has a new version that you can diff against old ones if you care. It makes reviewing the patch set in totality trickier. However, since I’m practice you want individual commits within a set to be standalone ones, I’ve rarely missed the ability.

<plug>In https://reviweable.io, you can have both matching-commit diffs and whole-PR diffs, all in the same review.</plug>

I think you typo'ed your plugged domain name. :)

Dammit! I mean, uh, it was a clever marketing ploy to attract attention and you totally fell for it. Yeah, that's the ticket.