

In non-minimal changesets, I would miss information/documentation about individual logical changes that make up the changeset.
It’s usually possible to find this by navigating back to the PR which you can find referenced in the squash commit.
I guess this might be a larger problem for codebases not following a trunk-based approach, where PRs grows to very large sizes before going into the mainline branch.
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.