1 commit == 1 reviewable unit == 1 PR == 1 CL == 1 feature == 1 fix is a perfectly reasonable way of working.
I used to work at companies where no one squashed their commits and the entire git logs were filled with 80% non-sense like "temp" or "bad" or "working" with the other 20% being coherent changes. What's the point of doing this I ask?
Well are we talking about commits pre- or post-merge? I don’t care how many commits you put into the PR / MR as long as they squash down to a single commit upon merge.
it lets you maintain version history when working, then most workflows auto squash on merge
there is an inbetween .... i insist people interactively rebase those commits out. In some contexts it is actually important to have traceability of iterative proof of work towards the final result.