Stacked PR landing workflow is awkward whether landing from bottom or top

[omry]

What is the recommended way to land a stacked GitHub PR series with Sapling?

I created the stacked PRs with sl pr submit. For a stack like:

B  top PR
A  bottom PR
main

I tested both obvious landing workflows on GitHub, and neither was a good
experience.

If I land the bottom PR first:

1. A lands.
2. The remaining PR for B can still carry the old local copy of A.
3. GitHub may show B as conflicting.
4. Recovery requires a manual loop:

sl pull
sl rebase -s <first-still-open-commit> -d remote/main
sl pr submit

Then repeat for the next PR.

If I land the top PR first:

1. The final combined diff lands on main.
2. The lower PR remains open.
3. The lower PR becomes conflicting/dangling and must be closed manually.
4. The stack is effectively collapsed into the top PR rather than landed as a
   stack.

So bottom-first becomes a land/rebase/submit loop, while top-first leaves lower
PRs behind.

Is there a Sapling-native workflow for landing a stacked GitHub PR series
cleanly? Ideally Sapling would either provide a command for this, document the
expected sequence, or guide recovery when a landed lower GitHub PR leaves the
remaining stack carrying an already-landed commit.

[vegerot]

Have you tried https://reviewstack.dev/ e.g. https://reviewstack.dev/facebook/sapling/pull/1249 ?

[omry]

Yes. if there is a land option there I was not able to see it.
I know Meta got a single atomic land pipeline which lands the entire stack and ensure that once landed tests are passing.
While typical OSS projects do not have the same throughput of lands and thus don't require this infrastructure - the desire to land a stack in a single action is still there and as far as I can tell - not covered by current out-of-meta Sapling.

[omry]

Update: GitHub now has a private preview of native Stacked PRs, and my personal repositories have been enrolled. I have not tried it yet.

This seems directly relevant to this issue: GitHub documents focused PRs, stack navigation, cascading rebases, and atomic stack merging. GitHub also provides gh stack link as a generic interoperability path for users managing their local stacks with tools such as Sapling.

This feels closely aligned with ReviewStack’s stated goal of “motivating the conversation about how an ideal stacked changes workflow should work.” Are there plans to add formal Sapling support for GitHub’s native Stacked PRs? I would be happy to try an early integration and provide feedback.