This message was deleted.

Not a graphite dev, but you can't just do it like that because that way PR number 4 by Alice won't be merged if PR number 3, completely independently developed by Bob, is scheduled on the merge stack before the other and fails to build

Sure, a failing build kicks it out of the queue and forces everything after to be rebased again. But you're still never worse off (except I guess in CI credits), since in the current state of affairs none of those PRs later in the queue have started CI yet at anyway

You are right that if the amount of runners and credits is not a limitation it's not worse than now

Hey @Ben Kay this is something we’ve been experimenting with internally but @David Bradford can explain the complexities and tradeoffs involved

This is something we have started to investigate and would like to build out at some point, but there are some subtle challenges for doing this with non-stacked PRs. The merge queue enforces a linear history with the PRs that are merged and the nice things about stacks is that they already have a linear history between the PRs in the stack. So when merging we can just rebase the entire stack on top of the latest commit on the trunk branch, then as CI passes we can quickly fast-forward the trunk pointer up the stack. For non-stacked PRs, we could potentially take some number of unrelated PR in the queue and "stack" them on top of each other to get similar concurrent CI runs. But it isn't quite that simple for the following reasons. The biggest issue is that we would like to ensure that the state of the PR in GitHub still makes sense. By rebased unrelated PRs on top of each other, the GitHub metadata for those upstack PRs is no longer accurate...the PR will either look like it contains the changes from all the unmerged PRs that it was stacked on top of, or we could update the base branch to make it look like it was not based on the trunk branch. Both of those are inaccurate representation of what is actually happening and we would really like to ensure that PRs are an accurate representation of what the PR is changing. Another issue that is easier to deal with but still more complicated than in the stacked case is error handling. If a PR in the middle of a group we created hits some issue while we are trying to merge it, we should fail the merge of that PR, but then need to go back and be sure to restack the PRs above it with the failed PR removed.

Thanks David - the GitHub PR part makes sense. I hope you can figure it out! At the moment it’s still not a clear-cut argument as to whether the merge queue is a net-benefit to us. Definitely on a days where there’s some big stacks, but days like today where I merged a load of dependabot PRs, I held everything else up from merging for like two hours 😅 Personally I’d take some transient weird base-branch shenanigans, but understand it might not be to everyone’s taste