Reproduce step
Let's say you have this stacked PRs.
main <- PR#1 <- PR#2 <- PR#3
Now, you manually create merge commit and push it to the main.
prv_main <- PR#1 <- PR#2 <- PR#3
\---------------------+-------new_main
Current Behavior
PR#1 is closed, because it's base is main, and GitHub automatically closes already merged PRs.
PR#2 and PR#3 are NOT closed, because their bases aren't main (they point to previous PR's tip), so they still have diff remaining, and PR isn't closed.
Expected Behavior
- All PRs should be closed.
How to fix this
Stacked PR should check it's mergeability against the whole stack's base (e.g. main in this case).
Basically the whole point of stacked PR is that "your PR is pointing to another PR, but they are treated as pointing to base".
Why this should be fixed
- These PRs are shown as "open PRs" while they are already merged.
- This will help 3rd-party integrations -- e.g. bors manually creates octopus merge commit of PRs and push it to main.
I know that you can manually gh stack sync, but I think this should be done automatically.
Reproduce step
Let's say you have this stacked PRs.
Now, you manually create merge commit and push it to the
main.Current Behavior
PR#1is closed, because it's base ismain, and GitHub automatically closes already merged PRs.PR#2andPR#3are NOT closed, because their bases aren'tmain(they point to previous PR's tip), so they still have diff remaining, and PR isn't closed.Expected Behavior
How to fix this
Stacked PR should check it's mergeability against the whole stack's base (e.g.
mainin this case).Basically the whole point of stacked PR is that "your PR is pointing to another PR, but they are treated as pointing to base".
Why this should be fixed
I know that you can manually
gh stack sync, but I think this should be done automatically.