I've never really understood the hate for a merge-based workflow for that exact reason. Having a true history is more important than having a clean history. (And "git log --first-parent" gives you a clean history, too.) Rebasing for a pull request means there is no way to tell that my local branch has been merged in, because the commit I made has disappeared into the aether.
I feel there’s a desire to organize everything in perfect little buckets based on one hard time dealing with a smorgasbord of various commits - but normally nobody even looks at them and it should be very easy to find the ones with substantial comments.
* Branch can be reduced to a single, coherent commit: squash + rebase
* Branch can be reduced to a single commit plus one or two unrelated fixup commits (like formatting): rebase
* Multiple commits: merge
But that requires value judgement and can lead to discussions, so it's not ideal for many teams.
Of course then there are also a lot of companies that use Jira as their primary source of history, where most commits are just "Fix ABC-123". For those it really doesn't matter much what you do to the Git history anywway.
