[xnorswap]

Okay, I guess this is also a consequence of having long lived branches that multiple people contribute to versus short-lived continuous integration into main.

I can also see value there if you're not squashing commits at the PR level. I prefer just squashing commits so main becomes:

  - Feature 1

  - Feature 2

  - BugFix 1

  - Feature 4

etc.

The individual branches have the "dirty" history which can be useful, and main is kept neat by having feature of fix-level changes which are quality controlled through gated-commits.

If you had to work on long-running feature branches which were more of a free-for-all so /branches/feature effectively becomes your "main" then I could see much more of an argument for re-writing history of individual contributors before merging into that feature branch.

I'd still argue you should just set up proper quality control on the feature branch and squash commits going into that, but that's the kind of overhead that can frustrate some teams, so I can better understand now the desire for a half-way cleaning between squashing and the full dirty history.