Do people actually share PR as in different people contributing to the same branch?
Also I can understand not squashing if the contribution comes from outside the organization. But in that case, I would expect a cleaned up history. But if every contribution is from members of the team, who can merge their own PR, squash merge is an easy way to get a clean history. Especially when most PR should be a single commit.
We do. If we are building out a feature, none of its code is merged into main until it is complete (if this is a big feature, we milestone into mergeable and releasable units).
The feature is represented by a Story in Jira and a feature branch for that story. Subtasks in jira are created and multiple developers can pick up the different subtasks. There is a personal branch per subtasks, and PRs are put up against the feature branch. Those subtasks are code reviewed, tested, and merged into the feature branch.
In the end, it is the feature branch that is merged (as a single merge commit and complete unit) into main, and may well have had contributions from multiple people.
I get your POV, but I’ve always considered that long-lived branches in the canonical repo (the one in the forge) other than the main one should be directly related to deployable artifacts. Anything else should be short-lived.
There can be experiment on the side that warrants your approach, but the amounts of merge going back and forth would make this hard to investigate (especially when blaming) I would prefer to have one single commit with a message that describe every contribution.
Unlike merge strategies, where squash-to-merge is almost always motivated by someone not knowing how to use the tools well, branching strategies can be very diverse and project-dependent for very good reasons. Some projects have to maintain multiple versions of the thing they produce simultaneously, others don't. Some projects effectively maintain a patchset on top of some external upstream project, some are the upstream that's being forked by others - and some are somewhere in-between. Sometimes you break half the world to slowly fix it afterwards in a long running refactor, often you don't. Often there's a single canonical repo where all work happens, sometimes there's not. There's no genuine one-size-fits-it-all, but fortunately, git is very flexible there.
Blame, bisect etc. work well with histories with lots of back-and-forth merging, as can be easily seen in Linux, so blaming is definitely not a reason not to do it this way if your project calls for it otherwise. Perhaps one issue with such workflow is that some popular review tools aren't exactly great at letting you review merge conflict resolutions.
Somewhat Linux-like. You could probably improve it purely from a git perspective by letting subtask dependencies be many-to-many (the commit graph is a dependency graph), but what you have is probably best for your whole Jira workflow.
Also I can understand not squashing if the contribution comes from outside the organization. But in that case, I would expect a cleaned up history. But if every contribution is from members of the team, who can merge their own PR, squash merge is an easy way to get a clean history. Especially when most PR should be a single commit.