FR: support for cross-fork stacked PRs

The limitation that the source and target branch need to be on the same repository is a showstopper for my project's use of stacked PRs, and I expect it will similarly be so for almost any github project of nontrivial size. It's unreasonable to expect projects to grant all potential contributors branch creation permission, and my project would similarly consider it unreasonable to restrict stacked PR support to just some subset of trusted developers -- we don't want some developers to feel "second-class" to the extent we can avoid it.

I can understand how this restriction would arise -- presumably the repository associated with a PR is always the repository of the base branch, which requires the base branch (the previous PR in the stack) to be in the target repository for a stacked PR. But please consider ways in which it could be lifted, as the current limitation is a severe blocker to usage of this functionality.

Yes support for Stacked PRs across forks will be coming in a future update! We haven't gotten to it yet, but it is a high priority for us and on our roadmap.

To start with, we will support a stack that is fully contained within a fork, where the entire stack targets the original repo.

For example, a contributor who has a fork (user/buzz) of the original repo (org/buzz) could create the following stack:

frontend      → PR #3 (base: user/buzz:api-endpoints)
api-endpoints → PR #2 (base: user/buzz:auth-layer)
auth-layer    → PR #1 (base: org/buzz:main)
org/buzz:main (trunk)

We (podman-desktop) have recently been granted to use stacked PR for our organisation, however while trying it this morning I tried to create a stacked PR on my fork, and targeting our upstream repository, and the error message was mostly unclear, I had to dig out a bit, to understand the problem.

$ gh stack submit
Checking stack state...
Pushing to origin...
⚠ failed to create PR for [...]: creating PR: GraphQL: Head sha can't be blank, Base sha can't be blank, No commits between main and [...], Head ref must be a branch (createPullRequest)
⚠ failed to create PR for [...]: creating PR: GraphQL: Head sha can't be blank, Base sha can't be blank, No commits between [...] and [...], Head ref must be a branch, Base ref must be a branch (createPullRequest)
✓ Pushed and synced 2 branches

For our workflows, not being able to create a stack from fork's branches is a blocker as our team usually don't have permissions to push on the upstream repository.

In the meantime of this feature being implemented, it might be great to have a clear error message, so we understand what limitation we are facing.

Can't wait to see this feature support forks, as this is something I've been waiting for to use since the announcement!!

+1
This would be a huge unlock for us. The same-repo limitation is the main thing keeping us from adopting stacked PRs in our workflow, since we rely heavily on fork-based contributions.

Is there any sense of the timeline for cross-fork support, or whether it's on the roadmap at all? Happy to help test it once something's available, we'd love to use it.

@axel7083

For example, a contributor who has a fork (user/buzz) of the original repo (org/buzz) could create the following stack.

this isn't working as of today, I tried just creating 2 branches on a fork user/buzz (branch test-1 and test-2) and attempted to create 2 stacked PRs against the origin repo org/buzz (branch master), it will just error the same way that @axel7083 described.

⚠ failed to create PR for test-1: creating PR: GraphQL: Head sha can't be blank, Base sha can't be blank, No commits between master and test-1, Head ref must be a branch (createPullRequest)
⚠ failed to create PR for test-2: creating PR: GraphQL: Head sha can't be blank, Base sha can't be blank, No commits between test-1 and test-2, Head ref must be a branch, Base ref must be a branch (createPullRequest)
✓ Pushed and synced 2 branches

Yes support for Stacked PRs across forks will be coming in a future update! We haven't gotten to it yet, but it is a high priority for us and on our roadmap.

To start with, we will support a stack that is fully contained within a fork, where the entire stack targets the original repo.

For example, a contributor who has a fork (user/buzz) of the original repo (org/buzz) could create the following stack:
frontend      → PR #3 (base: user/buzz:api-endpoints)
api-endpoints → PR #2 (base: user/buzz:auth-layer)
auth-layer    → PR #1 (base: org/buzz:main)
org/buzz:main (trunk)

Any ETA yet, especially with the public release?

Stacks from a single fork are very important and should be prioritized (for the projects I help maintain, all prs from all contributors must come from forks, even from admins). But for the future, stacks from multiple forks should also be implemented. It is very common that I'd like to base my work off of someone else's pull request.

also: #18

Yes support for Stacked PRs across forks will be coming in a future update! We haven't gotten to it yet, but it is a high priority for us and on our roadmap.

To start with, we will support a stack that is fully contained within a fork, where the entire stack targets the original repo.

For example, a contributor who has a fork (user/buzz) of the original repo (org/buzz) could create the following stack:
frontend      → PR #3 (base: user/buzz:api-endpoints)
api-endpoints → PR #2 (base: user/buzz:auth-layer)
auth-layer    → PR #1 (base: org/buzz:main)
org/buzz:main (trunk)

Bump, any update? 🙏

Unstack PR B: record that GitHub stacks do not work from a fork

Thanks for committing to work on this feature!

For example, a contributor who has a fork (user/buzz) of the original repo (org/buzz) could create the following stack:
frontend      → PR #3 (base: user/buzz:api-endpoints)
api-endpoints → PR #2 (base: user/buzz:auth-layer)
auth-layer    → PR #1 (base: org/buzz:main)
org/buzz:main (trunk)

Importantly, approvals for PRs #2 and #3 should carry forward to their eventual merges into org/buzz:main, even though their initial base branches are in user/buzz. My main motivation for using stacked PRs is to pipeline reviews: reviewers should be able to approve each layer while earlier layers are still pending. Once PR #1 lands and PR #2 is retargeted to org/buzz:main, I shouldn’t need to request another review solely because its base changed.

Concrete public reproduction from today with an eight-layer stack:

Upstream: tobi/walgit
Fork: behinddwalls/walgit
Contributor permission on upstream: READ
Eight local branches form a real one-commit-per-layer chain and are all pushed to the fork.
The corresponding upstream PRs are tobi/walgit#85, #86, #87, #88, #89, #90, #91, and #92.

The local topology is:

main -> issue-77 -> issue-78 -> issue-79 -> issue-80 -> issue-81 -> issue-82 -> issue-83 -> issue-84

But every upstream PR has to target tobi:main. GitHub will not accept behinddwalls:issue-77 as the base of a PR in tobi/walgit, because that ref does not exist in the upstream repository. Opening the upper PRs against branches in behinddwalls/walgit instead would place those PRs in the fork, outside the upstream review queue.

The result is that the PRs are only documented as a stack. They are not structurally stacked, and each upper PR contains the cumulative diff from every earlier layer. That creates redundant review work and makes independent approval of each layer impractical.

The behavior proposed above would solve this exact case:

behinddwalls:issue-77 -> tobi:main
behinddwalls:issue-78 -> behinddwalls:issue-77
...
behinddwalls:issue-84 -> behinddwalls:issue-83

with all eight PRs represented and reviewed as one stack in tobi/walgit. Happy to test a preview implementation against this live stack.

Stacked PRs is dead in the water without this, and it's sad to see half a year has passed with seemingly no progress or updates.

No large open source project will allow contributors to create branches, and creating the PR from your own fork is the only possible way to contribute (and is also the "GH" way AFAICT).

Navigation Menu

Repository navigation

FR: support for cross-fork stacked PRs #46

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

FR: support for cross-fork stacked PRs #46

Description

Activity

skarim commented on Apr 17, 2026

axel7083 commented on Jul 17, 2026

matanzvili commented on Jul 22, 2026

zhpeng811 commented on Jul 31, 2026

IamCoder18 commented on Aug 1, 2026

asmeurer commented on Aug 9, 2026

jglick commented on Aug 10, 2026

JakubKorytko commented on Aug 19, 2026

wujingyue commented on Sep 30, 2026

behinddwalls commented on Sep 30, 2026

mkolesnik commented on Oct 15, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions