that's more of how squash was applied in the situation ... If they had huge commits then while squash might break it up a bit that's a problem with how the people did their work.

Myself I like to do PR and merges with code that can be logically comprehended quickly and doesnt break the build.

a lot of that is due to being emphatic to people that are doing the reviewing. I know they don't know the context as they aren't in the code so I'm showing them a snippet of it, say a new method in s single commit. Then another commit for another method. Finally a third one that actually does some new functionality by combining the two.

I figure that's good enough for people to see that unit tests passed on the two methods and that the system started getting errors after the last commit so to look there for faulty logic.