how do i speed up rebases in PR stacks in graphite? after a portion of a PR stack lands, graphite takes it upon itself to rebase. but, on a longer stack, that rebase takes forever: about 1 minute per PR. this is way too long for my workflows that at the moment involve 30+ PR stacks. can i disable the autorebase/autorestack on server? similarly, the merge queue seems to be going commit by commit when the PRs are submitted for merge all at the same time (the green button at the top right saying "Merge 35 PRs"). in the activity pane of the merge queue, i see commits landing about 1 minute apart - as if each commit is landing separately. but, i believe we have turned on the setting that only runs CI on the group of PRs together in the merge queue.

Hey! Two separate things. Autorebase after part of a stack lands: Graphite does that on the server today, and there is no customer setting to turn it off. On deep stacks it often lands around ~1 minute per PR because each PR is rebased serially (fetch, rebase, push, retarget). We are tracking the ask to make that async rebase configurable or disableable. Merge queue looking commit-by-commit: The MQ setting that runs CI on a group of PRs together is under Merge Queue Optimizations (Parallel CI / Batching, on top of fast-forward). That changes how CI is validated, not whether the activity pane still shows commits appearing one after another. It is also separate from CI Optimizations (the setting that skips mid-stack CI during normal restacks): *https://graphite.com/docs/merge-queue-optimizations* and *https://graphite.com/docs/stacking-and-ci* On your Graphite MQ repos (

oi-runtime

,

the-engine

), fast-forward rebase is on, but Parallel CI / Batching is currently off. If what you enabled was CI Optimizations instead, that would explain the mismatch. Turning on Parallel CI / Batching in MQ settings is the lever for group CI in the queue. LEt me know if this makes sense! Brett B Graphite Support

thanks; i think it makes sense. our repo admin says he did add graphite as an allowed actor, but we're still getting an error about that when i enable CI Settings. will look at it more closely

Yes, this is a gap in the product today. In order to do this you need to temporarily enable a classic Branch Protection Rule with graphite as the bypass actor, then turn on the CI settings. Once its passes that one time check on our end oyu can delete the BPR and the CI settings will remain and work

so a ruleset won't actually work?

Yes, rulesets will work, just need the BPR to pass the initial legacy check we have.

as i mentioned, our github repo admin said he did make a ruleset that allows graphite to bypass, but we still get the error when trying to flip the CI Settings switch

yes keep the ruleset, add an empty BPR with graphite bypass, enable CI settings, delete BPR