Hey @AnupRajput1234,

To get started, you can run this command in the GitHub CLI 😄

+1 — showing approval status directly in the stack view would make reviewing much easier. It would be even more useful to distinguish between approved, changes requested, and still awaiting review, so you can understand the state of the entire stack without opening each PR individually.

And gh actions status also! 🙌

Thank you for sharing your thoughts! We do show the "ready" status in the merge box. Are you referring to something else or you are asking to add the status to all the stacks views?

We do show the "ready" status in the merge box. Are you referring to something else or you are asking to add the status to all the stacks views?

Ready implies to me more of a status check then the approval status - a small indicator that it has been approved separate from required status checks would be helpful! (e.g. "Approved but required CI failing" is a different piece of information than "Waiting for approval, but all the checks are good to go")

It's what I'm looking for too. I have stacks of dozen of PRs and some PR have approved and some are not. It's really hard to tell from the list atm

Something similar here. I merged the PR1 into main (which i thought i'd have to do first), and then when I went to merge in PR2, it says "stack conditions not met" and I can't merge. No indication of what exactly that condition is. Guess I did something in the wrong order, but it's not obvious which order to do things in.

Turned out that the conditions that weren't met were just my standard blocking tests not having run yet. The tooltip was just confusing since it referenced the stack, when it was really just that ticket.

Yeah same, seems buggy !

It's the button in the top-right corner of this menu

Terrible design choice, the unstack icon is so hard to find...

Irritating that merging is all-or-nothing within a stack (for any PR above the bottom one). Why can't I just merge at least the top PR into the one below it to simplify the stack?

@rbell-mfj gh stack modify then fold the one PR into the other PR and apply.

unstack should be a green button with text.

Or sharing the entire stack as a single thing. Sharing link to a page that displays the entire stack would be great also.

That's a good point. Supporting stacked PRs across forks would make this much more useful for external contributors. Right now, requiring all branches to live in the same repository seems to limit the workflow mainly to contributors with direct repository access.

It would be interesting to see whether cross-fork stacking is planned, especially when a second PR depends on changes from an already-open PR in the upstream repository.

It would be interesting to see whether cross-fork stacking is planned, especially when a second PR depends on changes from an already-open PR in the upstream repository.

+1

For a large public organization, most people don't have the write access.

Even for non-public repos, having to grant write access to all contributors is an anti-pattern due to the lack of granularity in the GitHub RBAC model.

This is a key missing piece of this feature in my mind. The typical workflow of finding a project you want to contribute to on GitHub is that you make a personal fork, and push your changes there, creating a corresponding PR in the upstream repo.

And then you find another thing to fix, that touches the same code, but isn't a related feature. So your second topic branch and PR pulls in the commits from the first topic branch and PR. Super annoying for both contributors and reviewers to deal with.

Crossing fingers cross repo stacked PRs will make it in before release! 😊

As an OSS maintainer I want to be able to stack up a number of community PRs so that we can merge them as one rather than having to rebase all PRs each time one is merged. Obviously the lack of signing support is also going to break this workflow in the same way it breaks the maintainer rebase button and rebase merge strategy.

That makes sense, especially for infrastructure changes where deployment order matters. A per-stack option to enforce sequential merging could make stacked PRs much safer for workflows like Terraform.

It might be even better if each PR in the stack could be marked as dependent on the previous one, so the next PR becomes mergeable only after the previous PR has been merged successfully. That would preserve the intended deployment order rather than relying on reviewers to remember it.

yea, my expectation was that I would be able to consolidate prs in the stack incrementally. That workflow exists with feature branches, just in a more cumbersome way, and I was hoping stacks would help make that process easier

It even seems worse than that, because if I can't incrementally merge, then I have to respond to PR feedback in branching histories, so instead of starting on the leafs and reviewing and merging towards the trunk, I have to start at the pr closest to the trunk, and work my way out, resolving and re-resolving any merge conflicts along the way

Yeah, I think that's one of the biggest limitations right now. Being able to merge an intermediate PR independently would make stacks much more flexible, especially when each stage needs to be deployed or validated before the next one is merged.

It's a complete mess when using squash merges too. I thought it would auto-rebase the upstack PRs but that fails with merge conflicts due to the squash merge. I guess it only makes sense if (a) you're using merge/rebase commits and/or (b) you're going to merge the entire stack at once(?), though I'm not even sure that would work.

agree

https://github.blog/changelog/2026-07-30-stacked-pull-requests-are-now-in-public-preview/

Stacked pull requests are rolling out in public preview to all repositories over the coming days. Merge queue support for stacked pull requests is rolling out progressively over the coming weeks.

I think this means us merge queue users are out of luck for who knows how long.

This sounds like an important compatibility gap, especially for organizations that rely on Merge Queue for protected branches. It would be helpful to know whether stacked PRs are currently expected to work with Merge Queue, or if repositories using Merge Queue are intentionally excluded during the rollout.

If it is a rollout limitation, some documentation or an explicit UI message would also be much clearer than returning a 404.

Also looking for more clarity here

+1 this was super confusing to me.

yep same for me, and in the end I pulled manually master onto my lower branch, and there was actually no conflict at all (i don't know where it found it in the first place)

Same here, tried different times, not working. I have to it manually

came here to post the same issue , the new stacking PR feature is not indicating the merge conflicts

I don't think this "stacked PR" feature works at all with squash merging into main. We already stack PRs (P1 -> main, P2 -> P1, P3 -> P2, etc) and I thought the merge conflict issue with squash merging + stacked PRs was solved by this feature, but it really doesn't seem to provide any discernable benefit. I can't even squish my PR branches down to one commit and use merge/rebase commits without having the same problem.

Thank you for the feedback! Sharing this with the team

adding onto this it would be nice to be able to assign the same reviewer to a given stack. often you need the context from previous layers to review a given layer.

to add to this: if you take github up on its offer to automatically rebase the stack atop latest main, it rebases using entirely unsigned commits

To add to the wrong author:
I now checked what I see in git locally:
The author name is correct (my name) but the email address is set to the wrong address.

In one case, I get like My Name <SomeUserId+githubusernameofpersonthatmerged@users.noreply.github.com>.
In another case, it’s the full regular address of the other person merging.

We experienced this same issue, and it makes stacked PRs unusable in our org.

As soon as Github tries to rebase the second PR in the stack against the post-merge of the first, the commit becomes unverified, and the stack merge stops.

Also, some CI checks seem to either block the stack (because they are required, and are not run or cannot be run) or cause a timeout (because the CI checks take a long time).

I would expect the following:

1. The commits to be merged are frozen when the stack merge begins, and cannot change during the stack merge.
2. When merging a stack, CI must pass before starting the merge, so it should not be re-run during the merge.
3. Approvals are considered prior to the stack merge, and are not dismissed during the stack merge.

We're facing the same issue with the author and squash-merge.
Even the 1st PR in queue was reassigned to the reviewer as the author.

While the feature is generally amazing, this is a blocker.

The team is currently working on a fix. Thanks for sharing 🙏🏼

That would be done via git rebase-onto, maybe they have to figure out a way to use rebase-onto when rebasing the whole stack.

I've double checked this, and Graphite does indeed handle this automatically, although idk how exactly

Graphite repro

trunk='canary' # trunk branch in my repo, adjust to 'main' or whatever's appropriate in yours
git switch "$trunk"

# create 'test/branch-1' (first in the stack)
git switch -C 'test/branch-1'

echo 'one' > one.txt
git add one.txt
git commit -m 'one'

gt track --parent "$trunk"

# create 'test/branch-2' (second in the stack)

git switch -C 'test/branch-2'
echo 'two' > two.txt
git add two.txt
git commit -m 'two'

gt track --parent test/branch-1

# go down the stack to 'test/branch-1', amend
git switch test/branch-1
echo echo 'one (amended)' > one.txt
git add one.txt
git commit --amend --no-edit

# restack to incorporate the update into test/branch-2
gt restack

gt restack updates 'test/branch-2' to be on top of 'test/branch-1' without any further input.

gh stack repro

$ gh stack --version
gh stack version 0.0.5

trunk='canary' # trunk branch in our repo, adjust to 'main' or whatever's appropriate in yours
git switch "$trunk"

# create 'test/branch-1' (first in the stack)
git switch -C 'test/branch-1'

echo 'one' > one.txt
git add one.txt
git commit -m 'one'

# create 'test/branch-2' (second in the stack)
git switch -C 'test/branch-2'
echo 'two' > two.txt
git add two.txt
git commit -m 'two'

# make a stack
gh stack init test/branch-1 test/branch-2

# go down the stack to 'test/branch-1', amend
git switch test/branch-1
echo echo 'one (amended)' > one.txt
git add one.txt
git commit --amend --no-edit


# restack to incorporate the update into test/branch-2
gh stack rebase

gh stack rebase fails with:

Rebasing branches in order, starting from test/branch-1 to test/branch-2
✓ Rebased test/branch-1 onto canary
⚠ Rebasing test/branch-2 onto test/branch-1 — conflict

Conflicted files:
  C one.txt

@lubieowoce i see in your logs that you're on gh stack v0.0.5. We released a fix for handling rebases on amended commits in v0.1.0. Can you try upgrading (gh extension upgrade stack) and let me know if that resolves the issue? Thanks!

yup, works as expected on 0.1.0. sorry for the confusion!

this works much better in 0.1.0, which saves a default remote.

(bear in mind, gh stack needs to be updated separately)

gh extension upgrade github/gh-stack

Update: Found this documentation on optimizing CI for stacked pull requests, which clarifies that workflows are evaluated against the stack base and that github.event.pull_request.stack.base.ref exposes the eventual target.

That helps us distinguish the direct base (github.event.pull_request.base.ref) from the stack base.

One question remains: for a stack such as A → B → develop, which branch-protection rules and required checks apply to A → B? Does it need to satisfy requirements from both B and develop, or only from the eventual stack base?

I've noticed this, as well. Stack merging breaks approvals when branch protection rules are enabled

same issue for me. blocks be from using them

Thank you for sharing your thoughts, this is currently on our backlog 🙌

Good Catch! thank you for reporting

@generall Thank you for sharing this feedback! The team is aware of the need to support admin bypass rules and will be working on it.

@rollokd Does your repo enabled merge queue with squash merging?