Reordering commits in stack can incorrectly close a PR

[neildhar]

When reordering two PRs in a stack, pushing the updated stack causes the PR moved down in the stack to be auto-closed.

For example:

touch A
sl addremove
sl commit -m "A"
touch B
sl addremove
sl commit -m "B"
sl pr submit

# Rewrite the stack from A, B to B, A
sl histedit 
sl pr submit

PR for B will be auto-closed. Confusingly, GitHub will actually report it as "merged" into main, even though nothing has actually been merged. (e.g. neildhar/test#2)

This seems to happen when the branches are pushed. After the first round we have:

• First PR merging prA -> main
• Second PR merging prB -> prA

My understanding is that we only update the PR metadata after all branches are pushed. So when we push both branches, the second PR appears to have already been merged, because its commit is present in the base branch prA, and GitHub closes the PR as merged.

If so, perhaps one possible solution is to interleave the pushing the branches and updating the PR metadata. That is, instead of:

1. Push branches prA and prB
2. Update metadata for first and second PR

We do:

1. Push branch prB
2. Update metadata for second PR to be prB->main
3. Push branch prA
4. Update metadata for first PR to be prA->prB