This message was deleted.

cc @David Bradford + @Jacob Gold

Hi Oleg! What you're noticing here is that we only rebase the PR if it needs to be rebased before merging. To explain further — if the same file is changed in consecutive PRs, they will need to be rebased as they merge, otherwise they won't (due to merge and rebase having slightly different methods of detecting a conflict). So what you're noticing here might be that in this stack the PRs didn't need to be rebase, whereas in some other they did. Rebasing each PR in the stack if not necessary would result in slower merges, especially for our users with longer CI runs (or even worse, flaky CI checks). We're considering a toggle in the merge stack that allows this to be chosen at queue time.

Hey Jacob, thanks for explaining! I guess the reason you see the bigger diff in the github UX is that when the automatic base change happens, it's to the base that existed prior to the merge and not the latest one. I understand this is an optimization but wonder if Graphite could work around that and somehow show a cleaner diff? Also as far as improving CI runs merge queues could help there https://github.blog/changelog/2023-02-08-pull-request-merge-queue-public-beta/

We're considering a toggle in the merge stack that allows this to be chosen at queue time.

That would be amazing. I'd even go as far as make it an org-wide setting with no possibility of deviating from it (if an admin chooses to). Similar to how you may want to enforce that the only legal merge strategy is "squash + merge" (which we do).

Exactly what I've been thinking! org- and repo-level settings like this will be part of our upcoming merge queue offering (the "queue" part is optional 😉 )— if you're interested in getting your team signed up as a design partner, I would recommend chatting with @Carissa Jansen

Thanks Jacob! On queues, frankly the GH version of merge queues being in GA makes me lean towards it (tight coupling to CI/CD or branch protection, already paid for, obviously works for team members not using Graphite — and we’re on monorepo so even more important, etc). GH has had its stability issues too, but again frankly — I see more stability issues in Graphite than in GitHub lately (which is expected — you ship more and you should!) But still very interested to have a chat about what a Graphite-powered merge queue would mean for us — because some of our assumptions may be wrong.

Cool to see the option appear in the UX recently, great work!