[Izkata]

For me, it's useful to peek into the thought process behind the commits if I notice something odd or interesting in the aggregate review. On occasion I end up with a totally different set of comments because I find they'd already tried something I was going to suggest.

More important to me, the "logically split" commits are less useful when hunting down a bug months or years later. They explain the final intent, but not the path to get there, when the path to get there reveals when the bug was actually introduced, and following the thought process using those original commits reveals what the developer was intending instead of just what the end result was.

For example, was the bug introduced in the refactoring/cleanup? This happens a lot, and an earlier state of the code reveals what it should be doing. Was it introduced during initial development? If so, is it just an edge case they didn't think about (because it should have been impossible and a recent change elsewhere made it possible), or is it a remnant of some earlier version of the feature? ..etc

(That remnant-of-an-earlier-version one has actually happened to me and straight removing some code rather than trying to fix it was the correct way to handle it)