[ycombobreaker]

> Branches where there's enough history to be worth maintaining multiple commits should - 99% of the time - be separate PRs.

I appreciate that anyone saying this is probably already on the same wavelength as me, but I don't find this to be true for myself. Many times, complex application features end up represented as a series of related, but atomic/meaningful changesets. I want the pull request to make sense as a whole, but expect that code review or audits are easier to accomplish diff-by-diff.

I see it like building a recipe. I want to hide all of the false starts, sloppy mistakes, do-overs, and checkpoints, because they are useless from a historical standpoint. But I still may want to publish a sequence of changes that accomplishes something.

[IshKebab]

Yeah that's fine, you can just push the series of commits and then squash them when they are merged. Both Gitlab and Github can do squash merges.