[epage]

Excited to see more stuff in this space. I've previously done some investigation into the various options [0]

Questions:

- Why have your own pre-conditions rather than relying on Github's built-in conditions and Status?

Ideas

- Autosquash fixup commits. I like to have multi-commit PRs that get merged into main. I'd like to leave my fixup commits up to make it easier for reviewers to see fixes and then have the tool doing the merge fix them up for me rather than doing yet another CI run for the fixups

- What about AzDO's semi-linear rebase option? This rebases a branch and then creates a merge-commit, keeping history linear

[0] https://epage.github.io/dev/submit-queue/

[ankitdce]

Wow this is amazing. May be you should add MergeQueue to your list :)

- Yeh we define our own pre-conditions because some developers also use it for non-protected branches. The default picks up the Github build-in preconditions and allows you overwrite. - 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? - Just read up the AzDO's semi-linear rebase.Yeh MQ should be able to do that as well. You can specify different config for rebasing the branch and for merging the PR.

Curious since you have done this much research - have you built or used any of the merge queues in your company? Would love to chat more. ankit[at]mergequeue[dot]com

[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.