Repository navigation
FR: support for cross-fork stacked PRs #46
Description
Activity
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)Reacted by Tatsat (Tats) Mishra 🐉, Brad Davidson, Helena Kotas, Michael Rooplall and Goober5000Reacted by Richard Smith, Chandler Carruth, josh11b, Nicholas Bishop, Corentin Jabot, Geoff Romer, Prateek Rungta, axel7083, Heba, Jordan Liggitt and 16 moreWe (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 branchesFor 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!!
Reacted by Tatsat (Tats) Mishra 🐉, matanzvili, Jacob Faibussowitsch, axel7083, Brad Davidson and Wolf-Martell Montwé+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.
Reacted by axel7083 and Mathijs MarkvoortFor 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 repoorg/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 branchesReacted by axel7083Yes 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?
Reacted by Divyanshu Dhruv, axel7083, David--Cléris Timothée, Alex Launi, Mathijs Markvoort, Jonathan Swartz, Jakub Korytko and Michael RooplallStacks 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.
Reacted by axel7083, Mathijs Markvoort, Asaf Ben Natan, Stuart Mumford and Mike EdmundsYes 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? 🙏
Reacted by 👑 Edward Sammut Alessi and Jon KoopsReacted by axel7083- added a commit that references this issue
on Aug 19, 2026 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
#2and#3should carry forward to their eventual merges intoorg/buzz:main, even though their initial base branches are inuser/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#1lands and PR#2is 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-84But every upstream PR has to target
tobi:main. GitHub will not acceptbehinddwalls:issue-77as the base of a PR intobi/walgit, because that ref does not exist in the upstream repository. Opening the upper PRs against branches inbehinddwalls/walgitinstead 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-83with all eight PRs represented and reviewed as one stack in
tobi/walgit. Happy to test a preview implementation against this live stack.- Upstream:
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.