[epage]

> - Can you clarify your fixup commit suggestion? So there's typically an option to squash and merge when merging the PR, but sounds like you want to maintain some of those commits and squash the rest?

If you run `git commit --fixup <ref>`, git will mark the commit as a fixup for `<ref>` (via a commit message convention). Then when you run `git rebase -i --autosquash`, git will automatically move those commits to be just after what they fix and mark them as "f" (fixup) rather than "p" (pick).

When putting up PRs for review, there is a tension between making it easy for reviewers to see what has incrementally changed (depending on which PR tool you are using) and having your PR in a ready-to-land state. By having fixups resolved during the merge, you get the best of both worlds.

> Curious since you have done this much research - have you built or used any of the merge queues in your company?

At my last company, I was researching what we should replace Phab with. I was looking at a broad spectrum of features for our system, including auto-merge, merge-queues, configuration-as-code, "next step" notifications for PRs (rather than flooding all), auto-elect-from-group with load-balancing, etc. Basically, we were in a bit of an extreme for baby sitting the system and I wanted to get us to the complete opposite. Unfortunately, I left before I got to complete that work due to a unique opportunity.