That kind of commit quality should only really be permissible on private projects, and as a reviewer, it's arguably acceptable to reject PRs with this kind of history.

You should be writing your commits to the benefit of the code reviewer - structure them in a logical fashion to tell the story about the changes you want to get merged.

For non-trivial branches I usually soft reset to the point where all code is unstaged and uncommitted and then curate the commits to align with what the reviewer should be reading. It's not uncommon for me to have several branches containing a single "wip"-commit which I amend onto while building up the full code for the branch.