we're noticing that when we have a stack of say 10 PRs, instead of doing something akin to a fast-forward merge so that all of those PRs can be merged very quickly, graphite decides to merge them one at a time and confusingly, its resulting in merge conflicts/dismissals even while we're not allowing any other members in the team to merge — the stack merge is the only thing going on. we have enforced few status checks in CI for the repo, and also have squash-merge enforced across the org. are these affecting graphite adversely or is this behavior expected and something to do with how git works?

(If applicable) To help us more clearly understand what you're trying to do, please provide additional details about: - Screenshots / debug logs / list of commands you've tried to run so far - Your workflow - Current state

CI optimization: yes (10 downstack PRs) merge queue: no

based off of what i'm seeing, this would be a perfect use case for using merge queue. with merge queue, rather than being merged straight into main, the PR will enter a queue and wait its turn to be merged which would decrease the merge conflicts/dismissals.

thanks Josie for the response. we do want to adopt MQ some day soon but was hoping there was some other cause for this.

yeah if you're using regular github merge or an external merge queue, graphite has to merge one by one while rebasing along the way