[CRConrad]

> There are broadly two approaches to git commit history: (a) it should reflect the historical development process; and (b) it should be cleaned up and pretty.

Can't you have both? Like, before you squash-merge your feature branch into main, you branch a new "feature archive" branch off it -- shouldn't that keep the more detailed history in that branch, even as the original feature branch gets rewritten? Then you'd get both a nice and pretty linear main -- well, not exactly "linear", in the sense that there are still lots of "dead" feature-archive branches off of it, but the "clean history" club can just ignore those -- and the full commit history of each feature for more detailed spelunking. Hmm, suppose it depends on whether squash-merge deletes old commits or creates new ones to replace them; feels like if they're in the ancestry chain of an "archive branch" they should be preserved there.

___

Parenthetical:

> If you're taking approach (b), then the maintainer is responsible for rewriting commits (e.g. squash merge).

Do they really have to be? What if the project policy states "Only submit PRs with nice and pre-cleaned history."?