This message was deleted.

Hi @Ben Jaffe, if you use the Graphite MQ, instructions for that are located here!

Ah got it! So this exists, and is live, but only if we're using merge queue.

the label works for all users, Github only, or Graphite

but what if I'm not using the merge queue?

the experts can correct me here, but i think the idea is: 1. You can turn on and configure merge queue 2. Graphite users can use the merge queue natively from the web UI 3. all github only users can simply add a label to get merge when ready/merge functionality, even though they aren't currently using Graphite

If we're using MQ, do we need to prevent people from merging via the GitHub UI? Or can some people use MQ and others don't stack and do the normal Github thing?

great question, i'm not sure

OK, so the configuration requires the graphite bot to have permissions to merge to

main

. I'm still a bit hesitant though since the docs don't explicitly reassure that interop is supported and we won't run into big issues.

i agree this is a documentation gap (i posted to our docs channel about it)

Like, a few of the questions I have: 1. What happens if someone manually merges a PR that's in the Graphite merge queue? 2. What happens if someone merges a pr via Github that's at the bottom of the stack, and then the rest has automerge on? 3. More broadly, the Graphite UI has a good number of regressions which leads to people feeling bearish -- how comprehensively is this core merging behavior tested and solid?

Catching up on this thread.

Is there a future world where you turn the label on for users who aren't using the merge queue?

Our label based merge is currently only supported for the graphite merge queue. You could make a feature request to support it for non-merge queue merges, but there is work that would need to be done for us to support that.

If we're using MQ, do we need to prevent people from merging via the GitHub UI? Or can some people use MQ and others don't stack and do the normal Github thing?

Our MQ will support this, but it is not recommended. It tend to result in a bad experience for MQ users. You get all the pain of a MQ with non of the benefits. What will happen is that as the MQ is merging a PR (or stack), if a PR is merged outside the MQ, the MQ merge will detect that and restart the merge on top of the change that was manually merged. If there is a lot of activity outside of the merge queue, this can result is in MQ merges taking a long time, potentially being "locked out" of merging. Basically non-MQ merge "skip the line".

What happens if someone manually merges a PR that's in the Graphite merge queue?

In the MQ we check to handle if PRs have already been merged. Those should handle PRs being manually merged like this. However, there are some race conditions (like someone manually merges after we have checked if the PR is merged but right before we attempt to merge) that could lead to us marking a merge as failed when it was already merged.

What happens if someone merges a pr via Github that's at the bottom of the stack, and then the rest has automerge on?

By "automerge" are you referring to our "merge when ready" functionality. I believe that should work, but @Jacob Gold has more familiarity with that functionality than me.

More broadly, the Graphite UI has a good number of regressions which leads to people feeling bearish -- how comprehensively is this core merging behavior tested and solid?

I personally have been on a mission the last few months to get our merge reliability as high as possible. At this point, it is fairly solid. We do have to work through github, which occasionally causes some instability, but we have even been able to workaround a lot of those issues. We have a dashboard with all the merge failures that have occurred that I review daily and as a team we review weekly. So if we do see any issues cropping up, we can quickly address them.

Wowwww, this is a wonderful and super comprehensive response, thank you! That last piece is very confidence-inspiring.

There are 2 caveats to that. (1) there is a timeout setting in the MQ, if you add a timeout you could potentially hit that will spinning on other merges passing you. (So you probably don't want to add a timeout in this situation). (2) there is a small window right now where our MQ thinks that a PR is ready to be merge, but a PR from github gets merged before we are able to actually perform the merge. In that case, we may fail the MQ merge. It will depend on how things are configured. The MQ has a setting called "fast forward merge" which requires the merge to have a linear history. So if another PR interrupts that history, the merge will fail. This is a situation we should be able to detect and retry, we just haven't implemented it yet. Once we do, then I don't know of anything else that might because issues.

Awesome, thank you David, this is all wonderful information! I'm sure you're all super busy with building, but I think this has all the bones of a really good blog post ❤️