Good analysis there.

In my ideal situation, there are just two sizes of code reviews: tiny and medium-sized. Most of the medium-sized reviews have multiple small helper commits, leading up to usually one major commit, and then sometimes a tiny configuration commit at the end.

For example, I might build some utilities for a new feature in a couple of commits, tweak some other code, then write a large new feature behind a feature flag that’s turned off — and then write a tiny commit turning it on.

The tiny reviews are for independent tasks — documentation, tiny issue fixes, updating version numbers of dependencies and so forth.

At the developer’s discretion, they can decide a commit is “trivial” and not get a review. So far this has caused zero issues in my life.

I would add that code reviews should take priority over anything that isn’t an emergency or a calendared item (meeting, interview, etc, of which there should be few), because they are blocking.