Problem
Stacked PRs require every branch in a stack to live in the same repository — the docs state: "Stacked pull requests require all branches to be in the same repository. Cross-fork stacks are not supported."
This is not a permissions problem. I have write access to both the upstream repository and my fork. The blocker is the fork boundary itself: even with full access on both sides, a stack cannot start in a fork and land in upstream.
The workflow that does not work
- Fork
upstream → origin.
- Create
feature-a and push it to origin.
- Open a PR:
origin:feature-a → upstream:main. This works today — it is an ordinary cross-fork PR.
- Stack
feature-b on top of feature-a, push it to origin.
- Now I want that second PR to join the stack of the PR from step 3, in
upstream.
Step 5 has nowhere to go:
- A PR opened in
upstream must have a base ref that exists in upstream. There is no way to express "base = origin:feature-a" for a PR that lives in upstream, so the upper layers of the stack have no home in the repository where the stack needs to be reviewed.
- Opening
origin:feature-b → origin:feature-a instead puts that PR in the fork's PR list, split off from the step-3 PR. The two are not one stack, and upstream reviewers never see the layering.
So the stack I want is:
PR #3: origin/feature-c → origin/feature-b ┐
PR #2: origin/feature-b → origin/feature-a ├─ one stack, reviewed in upstream
PR #1: origin/feature-a → upstream/main ┘
and this cannot be created, in either repository.
Incremental stacking on an already-open PR
The second half of this is just as important: the stack is usually not planned up front. I open a single cross-fork PR first, keep working, and only later realize the next change belongs on top of it.
So it should be possible to take an already-open cross-fork PR (origin:feature-a → upstream:main) and attach a new layer to it afterwards, turning it into the bottom of a stack — rather than having to decide at creation time that this PR will be stacked, or having to tear down and recreate the existing PR.
Why this matters
Forking is not only the OSS drive-by contribution path — it is also a normal way to work when you do have access on both repositories: keeping topic branches out of the shared repo, working across an org boundary, or simply following a project's convention that all branches live in personal forks.
Right now the two features are mutually exclusive. If branches live in a fork, stacked PRs are unavailable; to use stacked PRs, every branch has to be pushed into upstream directly. That forces a choice between the fork-based branch layout and the ability to present work as reviewable layers.
For scale, from Octoverse 2025: 63% of all repositories on GitHub are open source or public, and 518.7M pull requests were merged across public and open source repositories in 2025 (+29% YoY). Every project whose branches live in forks is currently outside the reach of stacked PRs.
Proposed behavior
Allow a stack whose branches all live in a single fork, with the bottom-most PR targeting upstream:
origin/feature-a → upstream/main
origin/feature-b → origin/feature-a
origin/feature-c → origin/feature-b
treated as one stack in the upstream repository, with the existing permission and review model unchanged — each PR is still an ordinary cross-fork PR reviewed and merged by upstream — and no change to the underlying Git branch model.
Supporting stacks that span multiple forks (basing work on another contributor's open PR) would be a reasonable later step, but single-fork → upstream covers the common case.
Related reports
The request has come up repeatedly, and has been acknowledged, but has not shipped:
Five months after the roadmap confirmation, the v0.1.0 (2026-07-29) and v0.1.1 (2026-09-02) release notes contain no cross-fork work, and reports against the current release are still arriving (#509, two days ago).
I am filing this separately from #46 because the existing threads frame cross-fork stacking as an access problem for contributors who cannot push to upstream. The case above is reproducible with write access to both repositories, and it also covers attaching a stack to a cross-fork PR that is already open — which I did not see raised elsewhere. Happy for this to be folded into #46 if you would rather track it there.
Ask
Where do cross-fork stacks currently sit on the roadmap, and is there a target release for the single-fork → upstream case? Happy to test a preview build.
Problem
Stacked PRs require every branch in a stack to live in the same repository — the docs state: "Stacked pull requests require all branches to be in the same repository. Cross-fork stacks are not supported."
This is not a permissions problem. I have write access to both the upstream repository and my fork. The blocker is the fork boundary itself: even with full access on both sides, a stack cannot start in a fork and land in upstream.
The workflow that does not work
upstream→origin.feature-aand push it toorigin.origin:feature-a→upstream:main. This works today — it is an ordinary cross-fork PR.feature-bon top offeature-a, push it toorigin.upstream.Step 5 has nowhere to go:
upstreammust have a base ref that exists inupstream. There is no way to express "base =origin:feature-a" for a PR that lives inupstream, so the upper layers of the stack have no home in the repository where the stack needs to be reviewed.origin:feature-b→origin:feature-ainstead puts that PR in the fork's PR list, split off from the step-3 PR. The two are not one stack, and upstream reviewers never see the layering.So the stack I want is:
and this cannot be created, in either repository.
Incremental stacking on an already-open PR
The second half of this is just as important: the stack is usually not planned up front. I open a single cross-fork PR first, keep working, and only later realize the next change belongs on top of it.
So it should be possible to take an already-open cross-fork PR (
origin:feature-a→upstream:main) and attach a new layer to it afterwards, turning it into the bottom of a stack — rather than having to decide at creation time that this PR will be stacked, or having to tear down and recreate the existing PR.Why this matters
Forking is not only the OSS drive-by contribution path — it is also a normal way to work when you do have access on both repositories: keeping topic branches out of the shared repo, working across an org boundary, or simply following a project's convention that all branches live in personal forks.
Right now the two features are mutually exclusive. If branches live in a fork, stacked PRs are unavailable; to use stacked PRs, every branch has to be pushed into upstream directly. That forces a choice between the fork-based branch layout and the ability to present work as reviewable layers.
For scale, from Octoverse 2025: 63% of all repositories on GitHub are open source or public, and 518.7M pull requests were merged across public and open source repositories in 2025 (+29% YoY). Every project whose branches live in forks is currently outside the reach of stacked PRs.
Proposed behavior
Allow a stack whose branches all live in a single fork, with the bottom-most PR targeting upstream:
treated as one stack in the upstream repository, with the existing permission and review model unchanged — each PR is still an ordinary cross-fork PR reviewed and merged by upstream — and no change to the underlying Git branch model.
Supporting stacks that span multiple forks (basing work on another contributor's open PR) would be a reasonable later step, but single-fork → upstream covers the common case.
Related reports
The request has come up repeatedly, and has been acknowledged, but has not shipped:
gh stack submitfails on forks by attempting to create PRs on upstream repository (Head sha can't be blank) #509 (2026-09-13) —gh stack submiton a fork still fails on v0.1.1, resolving the stack against the upstream parent instead of the fork:Head sha can't be blank, Base sha can't be blank, ... Head ref must be a branch.gh repo set-default <fork>does not change it.gh stack link --remote <fork>queries the fork's parent repository.Five months after the roadmap confirmation, the v0.1.0 (2026-07-29) and v0.1.1 (2026-09-02) release notes contain no cross-fork work, and reports against the current release are still arriving (#509, two days ago).
I am filing this separately from #46 because the existing threads frame cross-fork stacking as an access problem for contributors who cannot push to upstream. The case above is reproducible with write access to both repositories, and it also covers attaching a stack to a cross-fork PR that is already open — which I did not see raised elsewhere. Happy for this to be folded into #46 if you would rather track it there.
Ask
Where do cross-fork stacks currently sit on the roadmap, and is there a target release for the single-fork → upstream case? Happy to test a preview build.