Not a single soul besides the one rewriting history knows what they're in for after the fact.

It's a recipe for disaster.

Unless you mean squashing commits, which I don't consider rewriting history, just a retelling of the fact. Still, it's something one can only do very sporadically, or at known periods of time. I

'm sure others would be more pedantic about it and this wasn't clear above.

The modern workflow is just to let GitHub squeeze yor shit commits into one and then rebasing that.

Hardly anything modern about it, but it's a way of keeping a somewhat sane history. Certainly better than merging 'fix' 'fix' 'fix comments' into master.

The thing is, we could have done better (and have been) since before git even existed.

The "squash everything" mantra turns git commit history into a series of snapshots devoid of any logical notion about how code evolves.

Squashed commits are strictly worse than plain, non-fast-forwarded merges from rebased branches.

Depends on your commits. If it’s untested noise I’d much rather they’re squashed so bisect doesn’t meander in trash.

Bisecting with --first-parent takes care of this.

There are legit reasons to have a series of commits within one PR, and rebase and merge them as is, and use amend/fixup and force pushes to maintain them cleanly.

It's not my favourite process, but...