That’s why I usually look at the diff of the whole PR and prefer to merge by squashing. Commits inside the PR are usually noise.
But LLMs appear to be pretty good at making small commits with sensible commit messages, that greatly help to make sense of the whole PR.
Regarding large monolithic commits, how do you even know where to start reviewing in a large PR? Smaller commits at least give you some sense of ordering.
What I’m saying is that large commits shouldn’t be a thing without out of band discussions (formatting, design refactoring, features merging). With such knowledge, it’s easy to glance at the code and understand the implementation.
Not every project can afford this.
>With such knowledge, it’s easy to glance at the code and understand the implementation.
I really doubt that this is true for large, legacy code bases, where one is only familiar with a small part of the system.
You expect to send a big PR to someone without him being aware of the context or without being available to discuss your solution?
> I really doubt that this is true for large, legacy code bases, where one is only familiar with a small part of the system.
Reviewers should already be knowledgeable about the part being modified. If no, the review is just for checking for antipatterns in the code, or badly written tests. A bit useful, but can be unnecessary in high trust (or keen on accountability) workplaces.