I refactored a critical long class that has very long member functions. My main intention was to:

• Extract many smaller member functions to enhance class modifiability.
• By breaking the long member functions into smaller ones, it will be much easier to understand what the class is really doing.
• By having many smaller member functions, we have the chance to discover if the class is not cohesive. We may then consider extracting a new class. This will be a good news as the class is already too long.
• Enhance the memory footprint for the main class API. 

I did many commits, each with a logical and small refactoring step. When the code is sent for code review, the reviewer complained of time wasted reviewing all these commits. He asked, for next time, can you make it one big commit?

No, we can not, and here is why it is better to have fine-grained commits.

If you are doing a real code review that you have to understand each change to ensure it meets quality checks, ensure there is no bug injected and evaluate side effects and to propose QA test cases to cover them, then one small logical commit is much easier and accurate to review. It will take time, but it is worth the time.

For the developer himself, I find it very crucial to commit changes bit by bit, ensuring logical and small change is committed and a good comment is written. It is like a self-review and organized way even before code review.

If still, the reviewer needs to see all changes in one shot, he can easily check out the old class and the final edited class and used any diff tool to see all differences at once.

Happy coding!