hey all - we were wondering why Graphite needs these temporary draft PRs when using the parallel CI feature in the merge queue. Unfortunately the docs only explain the how but not the why. We were wondering if it would also work with just temporary branches to avoid the PR spam?

(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

Hey Gary, thanks for replying. It makes sense for the batching. We were just wondering why it's also needed when using just the parallel execution without any batching? In theory it should be possible to just rebase the branch on its predecessor in the merge queue? We were trying to sell Graphite CI optimisations to our users. Unfortunately some users consider these temporary PRs and the wrong status of the original PR in Github (

closed

instead of

merged

) as show stoppers.

gotcha, yeah at this time the draft PR and

closed

vs

merged

status in GitHub is a necessary trade-off for using that optimization feature. Our team is in the early stages of exploring possible alternatives for the latter issue that would allow

merged

status in GH.

@Gareth Brickman can you say any more about timelines on these alternatives? We would love to use the Graphite MQ but for us closed vs merged is also a showstopper

hey Nikolaus, I believe the team is looking into allowing merge commits to be compatible with the other settings of the queue. There is no firm ETA though