A curated sequence of logical commits assembled into an idealized history is often much easier to review than the real history. However, to rewrite history wel

A curated sequence of logical commits assembled into an idealized history is often much easier to review than the real history. However, to rewrite history well enough for that you need.... * a solid understanding of interactive rebasing, including `fixup` and `reword`. * `git add -p` for adding partial sections of files * `git commit --amend` for patching the last commit * `git commit --fixup [COMMIT_ID]` for attaching patches to commits further back in history. * `git stash` for pausing progress while you fix up an old commit. * `git rebase -i --autosquash [COMMIT_ID]~` to apply the fixups * topic branches that never get too big or drift too far from the mainline, because rebasing often becomes infeasible when repo snapshots are too far apart. * A low enough error rate that you don't screw everything up when rewriting history (which is a reasonable critique and argument for why you shouldn't attempt this in the first place). I can usually manage this, and efficiently enough that it's worthwhile — and my colleagues appreciate that my PRs are easy to follow. But as a reviewer, I don't insist on other people putting in the same investment.