What should happen during a squash/rebase is that the semantic meaning of commits should be revised for maximum legibility of a future maintainer.
If you did one "thing" on a PR branch, and it took you 10 commits to do it, those 10 should be squashed to one, and the commit message should be "Added thing."
If you did 3 "things" on a PR branch, and it took you 10 commits, you should squash those 10 into 3 semantically meaningful commits: "Added Thing#1" "Added Thing#2" "Added Thing#3" This is doubly true if you ran into some complexity during the implementation that caused you to have to do the extra stuff -- that's exactly the type of detail someone looking back on commits needs to understand the development history.
This is something that you are not allowed to do under most squash-merge policies, because "1 PR == 1 commit" for maximum legibility.
Of course, nobody ever takes the time to do any of this which is how we ended up with such policies in the first place.
If you did one "thing" on a PR branch, and it took you 10 commits to do it, those 10 should be squashed to one, and the commit message should be "Added thing."
If you did 3 "things" on a PR branch, and it took you 10 commits, you should squash those 10 into 3 semantically meaningful commits: "Added Thing#1" "Added Thing#2" "Added Thing#3" This is doubly true if you ran into some complexity during the implementation that caused you to have to do the extra stuff -- that's exactly the type of detail someone looking back on commits needs to understand the development history.
This is something that you are not allowed to do under most squash-merge policies, because "1 PR == 1 commit" for maximum legibility.
Of course, nobody ever takes the time to do any of this which is how we ended up with such policies in the first place.