My reviewers love when I write “review commit by commit” in the PR description. Then each individual commit has its own reasoning, and you can mentally switch into reviewing if that commit does it’s one thing it’s supposed to do correctly. I will accept the argument that each commit should be its own PR though :)
The PR is just the best GitHub had to offer. There are other approaches to code review.
[1] Here we are generalizing.
It is not anemic like the squash workflow.
They do care. They go through the trouble of reviewing it so that the resulting commit[1] that lands in the upstream repository is good.
[1] Presumably you don’t mean “they don’t care about the commit that produced the patch”… since the patch is just a transport format for the commit.
Commits. Not everyone will care to clean up their local history just to produce a single patch. You can git diff it out.
EDIT:
I was using "patch" for diff so scratch the above comment. Even then, when using a forge, I'd rather use squash unless everyone clean up their commit history when producing a PR.