Stacked pull requests are now in public preview 🚀

[ebndev]

Stacked pull requests break large changes into small, reviewable pull requests. They're an ordered series of pull requests that each represent focused layers of your change. With stacks, you can independently review and check each pull request, then merge everything together in one click. No more opening a single large pull request that takes forever to review, or splitting work across multiple branches you have to keep manually rebasing.

"We've been using GitHub stacked PRs for Next.js for the past few months. It has helped us introduce smaller individual changes while shipping larger features, making it easier to review PRs. - Tim Neutkens, NextJS lead, Vercel"

072926-gitub-tmp-pr-v08.mp4

With stacked pull requests, teams can:

• Keep large changes moving by reviewing short, narrowly scoped pull requests in parallel.
• Maintain quality across every layer by using focused pull request reviews alongside existing branch protections to protect main.
• Merge one, some, or all by landing an entire stack altogether or individual layers one at a time.

And because stacked pull requests are built into GitHub, your existing reviews, checks, and merge requirements all work out of the box.

"The new Github Stacked PRs preview is incredible. Landing 5 stacked PRs directly to a merge queue all at once! A+++! This removes so much friction (and the gh cli tools + agent skill help a ton)" - John Resig, creator, jQuery

Get started with the CLI extension

Install the CLI extension and create your first stack in under a minute:

gh extension install github/gh-stack

Create stacks from your terminal or github.com

Create a stack from github.com, the GitHub CLI, the GitHub mobile app, or with a coding agent such as GitHub Copilot using the gh-stack skill. Start with a branch and pull request for your first change. Then add branches and pull requests on top of it; each pull request targets the layer below it.

Stacks-Changelog-InLine-01-CLI.mp4

Review each layer independently

Open any pull request in the stack to review only the diff for that specific layer. Use the stack map at the top of the pull request to see how the change you're reviewing fits into the larger work. You and your teammates can each review different layers in parallel without blocking further work.

"AI has made TED's developers dramatically more productive, but that created a new bottleneck: PRs were growing large enough that reviewers were struggling. Stacked PRs help to solve that. By breaking large changes into small, dependency-ordered pieces, review happens in smaller logical chunks - not just faster PR reviews, but more accurate ones. Stacked PRs tighten our feedback loop and help get stable code to ted.com faster." - Andy Merryman, CTO, TED

Merge everything in a single click

Merge the latest ready pull request to land it and every unmerged layer below it in one single operation. To land part of a stack, merge one or more lower layers—the pull requests above it stay open and automatically rebase and retarget. Your existing branch protections and required checks still govern what reaches main.

"A big change used to mean one giant PR nobody wanted to review. Now it's a stack of small ones reviewers can actually follow, and the whole stack merges in one shot. It stopped feeling like a tool on top of GitHub and started feeling like GitHub." - Mayank Saini, connectivity engineer, WHOOP

Stacks-Changelog-InLine-03-MergeBox.mp4

Find out more and share your feedback

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.

For more information, check out the stacked pull requests documentation, and share your feedback with us in the comments below!

[AnupRajput1234]

gh extension install github/gh-stack

[ebndev]

Hey @AnupRajput1234,

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

[abc18881999]

Resolving a merge conflict on GitHub

Resolve simple merge conflicts directly on GitHub using the conflict editor or handle complex cases via the command line.

You can resolve simple competing line change conflicts on GitHub. For other conflicts, use the command line. See Resolving a merge conflict using the command line.

If Copilot cloud agent is enabled for the repository, you can click Fix with Copilot in the merge box to have Copilot resolve conflicts automatically. See Using Copilot cloud agent on GitHub.

Warning

Resolving conflicts on GitHub merges the entire base branch into the head branch. If the head branch is the default or protected branch, you may be prompted to create a new head branch. See About protected branches.

1. Under your repository name, click Pull requests.

2. In the "Pull Requests" list, click the pull request with a merge conflict that you want to resolve.

3. Near the bottom of your pull request, click Resolve conflicts.

   

   [!NOTE]
   If Resolve conflicts is deactivated, resolve the conflict using another Git client or the command line. See Resolving a merge conflict using the command line.

4. Decide if you want to keep only your branch's changes, keep only the other branch's changes, or make a brand new change, which may incorporate changes from both branches. Delete the conflict markers <<<<<<<, =======, >>>>>>> and make the changes you want in the final merge.

5. If your file has more than one merge conflict, scroll down to the next set of conflict markers and repeat steps four and five to resolve the conflict.

6. After you've resolved all the conflicts in the file, click Mark as resolved.

   

7. If more than one file has a conflict, select the next file you want to edit on the left side of the page under "conflicting files" and repeat steps four through seven until you've resolved all merge conflicts in your pull request.

8. After you've resolved all your merge conflicts, click Commit merge. This merges the entire base branch into your head branch.

   

9. If prompted, review the branch that you are committing to. You can update the head branch or, if available, create a new branch for the pull request. If the head branch is protected, you must create a new branch.

   Click Create branch and update my pull request or I understand, continue updating BRANCH.

10. To merge your pull request, click Merge pull request. See Merging a pull request.

Further reading

• Pull request merges

[abc18881999]

Resolving a merge conflict on GitHub

Resolve simple merge conflicts directly on GitHub using the conflict editor or handle complex cases via the command line.

You can resolve simple competing line change conflicts on GitHub. For other conflicts, use the command line. See Resolving a merge conflict using the command line.

If Copilot cloud agent is enabled for the repository, you can click Fix with Copilot in the merge box to have Copilot resolve conflicts automatically. See Using Copilot cloud agent on GitHub.

Warning

Resolving conflicts on GitHub merges the entire base branch into the head branch. If the head branch is the default or protected branch, you may be prompted to create a new head branch. See About protected branches.

1. Under your repository name, click Pull requests.

2. In the "Pull Requests" list, click the pull request with a merge conflict that you want to resolve.

3. Near the bottom of your pull request, click Resolve conflicts.

   

   [!NOTE]
   If Resolve conflicts is deactivated, resolve the conflict using another Git client or the command line. See Resolving a merge conflict using the command line.

4. Decide if you want to keep only your branch's changes, keep only the other branch's changes, or make a brand new change, which may incorporate changes from both branches. Delete the conflict markers <<<<<<<, =======, >>>>>>> and make the changes you want in the final merge.

5. If your file has more than one merge conflict, scroll down to the next set of conflict markers and repeat steps four and five to resolve the conflict.

6. After you've resolved all the conflicts in the file, click Mark as resolved.

   

7. If more than one file has a conflict, select the next file you want to edit on the left side of the page under "conflicting files" and repeat steps four through seven until you've resolved all merge conflicts in your pull request.

8. After you've resolved all your merge conflicts, click Commit merge. This merges the entire base branch into your head branch.

   

9. If prompted, review the branch that you are committing to. You can update the head branch or, if available, create a new branch for the pull request. If the head branch is protected, you must create a new branch.

   Click Create branch and update my pull request or I understand, continue updating BRANCH.

10. To merge your pull request, click Merge pull request. See Merging a pull request.

Further reading

• Pull request merges

[jens-gilion]

My claude code workflow would love if the CLI allowed merging stacks as well.

Further, when the stack requires a rebase, the "merge" button is still green and seems to attempt a merge that will inevitably fail, this is rather frustrating as it takes quite some time for the UI to reflect this

[jcaudill-truepic]

Please show the PR approvals on the stack list and merge stack list!

[emilyrohrbough]

Came here to ask for this! 😃

[Ritik574-coder]

+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.

[victorDigital]

And gh actions status also! 🙌

[felixminom]

Idk if I did something wrong, but I did merge PR2 and then PR1 and only got PR1 merged to main. I had to merge main into PR2 and solve conflicts to be able to merge that one as well. In any case, I think it's not very intuitive what's going on; this was my structure:

• main
  • PR1
    • PR2

[daprezjer]

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.

[daprezjer]

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.

[benjaminclauss]

Thanks for the 🥞!

[binghamtj]

Can I unstack them so that I can merge things? Right now I have a PR to Branch A and cannot merge it because the PR from Branch A to Develop is blocking it, seems kind of dumb.

[binghamtj]

I found the unstack option, was not intuitive.

[beniusij]

On the website? I ended up using gh stack unstack instead.

[gracewhitney]

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

[diegorubert]

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

[rbell-mfj]

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?

[ImErvin]

A share button that copies the links to each PR in the stack so I can share with my colleagues when asking them to review

[d-feliz]

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

[isaksky]

It would be great if you made it so these new stack commands worked via github PATs - otherwise it will be a little dangerous with agents (you have to give them full access).

[dxqb]

this feature looks really promising, but I think it only becomes useful when a contributor who doesn't have access to the repo can stack PR submissions. unless I'm missing something, all branches must be in the same repo currently. They aren't when you submit a PR to another repo, and you might want to stack onto your first PR

[Ritik574-coder]

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.

[MrXnneHang]

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.

[ghicks-novaprime]

I have a use case for this that would be greatly improved with a pretty minor change.

Occasionally, I need to make a change that should be deployed in multiple separate steps. For example, removing an S3 bucket from a Terraform deployment - first I need to merge a change to enable force-destroy and apply that (so it can be removed without emptying its contents first), then I need to merge a second change to actually remove it.

Stacked PRs look like a great way to create both PRs ahead of time and mark them as related for reviewers, but I don't see any way for the stack creator to force the individual PRs to be merged separately. In the case I described above, someone merging both of them at once defeats the purpose and causes a failed apply.

If I could disable merging multiple PRs at once for a specific stack, it would be much more useful and safer for this use case.

[Ritik574-coder]

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.

[FatTailSec]

I lowkey dislike the github stacks feature they added
[2:19 PM]no ability to merge intermediate stages its all or one into the default branch

[bienjamon]

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

[bienjamon]

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

[Ritik574-coder]

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.

[nalvelo]

This feature is not currently working for any repo in our organization that has a Merge Queue. Is there any guidance of how to enable this? I verified this to see 404 vs. 200 statuses for the stack feature against all of our repos.

[igorserrao]

agree

[JarredAllen]

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.

[Ritik574-coder]

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.

[joerobot]

Also looking for more clarity here

[KyleBastien]

+1 this was super confusing to me.

[JeremasPosta]

Nothing indicates that there is a conflict:

Then, upon rebasing, a conflict exists on the 'current' PR

And now I don't have the web editor option to solve the supposed conflict.

[MarionToutant]

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)

[jcrodriguezu]

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

[SaiShankar93]

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

[danilofuchs]

Would be nice to be able to mark a whole stack as "ready for review" at once

[BethelH]

All commits before the stack are suddenly unverified even though no changes were made to my local signing ability, any commits pushed up after stacking are verified as usual

[PattaFeuFeu]

To add to that: I had a case where the merged commit (we use squash merge) to main was authored exclusively by the reviewer, not by me, the author of the PR and all its commits.

We’ve been using squash-merge without issues for years now. Usually, the author is either set to the PR’s author or the PR’s author plus the reviewer, if they changed anything to the code and added a commit. I never had it happen before that the author was switched entirely, erasing my name completely. 🤔

Edit to add: Happened again, one day later. So this wasn’t just a fluke.

[maxdeviant]

I've also run into this issue.

We're using squash merges, and if I merge the PR that someone else authored and opened (my name does not appear anywhere as an author), I am then attributed as the author in the commit on main (and the PR author doesn't appear at all).

[k-thornton]

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

[PattaFeuFeu]

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.

[jsync-swirlds]

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.

[ingowalther0]

Love the feature! My agents struggle with rebasing due to worktrees - multiple PR branches are typically checked out in different worktrees while gh stack tries to work on all PRs in the current worktree and that fails.

[oy-hyejin]

for usual pr, I can merge without approval when urgent, but for stacked pr, I can't merge it without approval.

[aranw]

IT appears unable to link PRs in a stack to a issue using the syntax shown on https://docs.github.com/en/issues/tracking-your-work-with-issues/using-issues/linking-a-pull-request-to-an-issue

[harel-vanta]

Multi-PR stack merge can't satisfy require_last_push_approval or dismiss_stale_reviews_on_push — the merge's own internal rebase invalidates the approvals it just evaluated as passing.

Repro on a private repo with a 7-PR stack — linear, every PR approved, all required checks green — where the ruleset protecting the trunk has:

• required_approving_review_count: 1
• require_last_push_approval: true
• dismiss_stale_reviews_on_push: true

gh stack merge <top-pr> --merge fails with:

✗ merge failed: Repository rule violations found

Waiting on 1 reapproval from someone other than the last pusher. Review from
<reviewer> is stale because it was submitted before the merge base changed.

The notable part is that this persists after a fresh approval. We obtained an approval that postdated every human push to the stack by two minutes, with the trunk not having moved all day, and got the same "stale because it was submitted before the merge base changed" message — now naming the brand-new review.

The rule-suite log explains why. GET /repos/{owner}/{repo}/rulesets/rule-suites?ref=refs/heads/<trunk> records one suite per stack layer per attempt, each with result: "stack_merge_failed" while every individual rule_evaluations[].result is "pass" — and each suite's after_sha is a commit that did not exist before the attempt. So the merge rebases every layer internally, and that synthetic push is what invalidates the approvals, after the rules have already been evaluated as passing. Nobody can approve those commits: they exist only inside the merge transaction.

Consequence: with require_last_push_approval: true, a multi-PR atomic stack merge cannot succeed no matter how many fresh approvals you collect. Disabling it just moves the failure to the other rule:

✗ merge failed: Repository rule violations found

At least 1 approving review is required by reviewers with write access.

— i.e. dismiss_stale_reviews_on_push now discards the (valid, admin-level) approvals mid-merge, leaving zero. With both rules off, the same command merges all 7 PRs immediately.

So at the moment a repo has to choose between stacked PRs and either approval-integrity rule. Merging one PR at a time is the documented workaround, but only the bottom PR needs no rebase, so every rung above it hits a retarget/rebase and needs a fresh approval — which is most of the value of stacking gone.

It would be ideal if the internal rebase were exempt from these two rules, or if approvals carried across it, given the diff each reviewer approved is unchanged.

Two smaller things found along the way:

1. gh pr merge (GraphQL mergePullRequest) refuses stacked PRs with "This pull request is part of a stack and must be merged using the asynchronous merge REST API." Clear message — but it means existing automation that merges PRs one at a time breaks the moment a branch becomes part of a stack.
2. Failed merges initiated from the web UI surfaced only as auto_merge_disabled timeline events with reason "Pull Request is not mergeable", with no indication of which requirement failed. The CLI's message was the only actionable diagnostic we could get. Surfacing that same text in the merge box would save a lot of guessing — we spent hours chasing the wrong causes before the CLI told us plainly.

[thedevtoni]

From the UI perspective, would be great to have a Feature Preview or as default to have the ability too see all the stack into one line in the pull request list.

[fmorrisey-capture]

Long-time user, first-time complainer.

We opted into stacked PRs expecting to stack small PRs into a feature branch. It did the
opposite — it blocked every child PR from merging, and the only fix was removing the stack.

The problem: two patterns, identical topology

• A stack is a short-lived chain merged as a unit, bottom-up, within days.
• An integration branch takes children continuously, merges last — often months later —
  and is deliberately unmergeable until then.

Both look the same: one PR's head is another PR's base. Inferring "stack" from that shape and
applying unit-merge semantics breaks the integration-branch pattern — and breaks it hardest on
long, complex features, where a blocked merge costs the most.

Our setup is the second kind: several small PRs into a long-lived integration branch, plus one
draft PR from that branch to development that stays open for weeks while the feature is built.

What happened

A child PR — approved, checks green, MERGEABLE, CLEAN — could not be merged by any means:
not the UI, not GraphQL, not PUT /pulls/{n}/merge, not the async endpoint. No override, no
admin bypass. The feature required the last merge before permitting the first.

Three defects

1. The error describes the wrong PR.

{"status":"failed","details":{"message":"Pull request must be open and not in draft mode in order to be merged."}}

Returned for a PR that was open and not in draft. It was describing a different PR in the
stack and never said which — four failed attempts to find it by elimination.

2. No valid state exists. Downstack PR as draft → "not in draft mode." Closed → "must be
   open." Open and non-draft → still blocked. For an integration PR that is deliberately
   unmergeable, no configuration lets a child merge.

3. The endpoints contradict each other. GraphQL and PUT /pulls/{n}/merge refuse and point
   to the async endpoint; the async endpoint UUID, then fails on an
   unrelated PR's state. Three errors, one root cause, none of them naming it.

This hit four concurrent efforts in one repo. The UI says only "Blocked downstack" — no PR, no
reason. Ordinary PRs to the default branchked broken globally.

Fixes, in order of value

1. Never remove single-PR merge. Make stac + green + CLEAN
   should always be mergeable.
2. Let us declare the pattern instead of i "integration branch,
   not a stack" marker.
3. Name the blocking PR in the error, and gree.

Reproduction (any empty repo)

1. Branch integration from main.
2. Open PR A: integration → main, as draft. (Non-draft with required reviews behaves the
   same.)
3. Branch child from integration, push a commit.
4. Open PR B: child → integration. Approve
5. Try to merge B — it can't be, by any endpoint. UI shows "Blocked downstack."

Close PR A and the async error flips from "not in draft mode" to "must be open."

Step 2 is the whole trigger, and it's legitimate: an integration branch not meant to merge for
months. Can't share our repo (private, proeproduces it.

[sb-tmp-97]

Please add support to GitHub Desktop

desktop/desktop#22660

[snawaz]

If I have "untracked" files locally, I shouldn't really get this error message.

≻≻ snawaz ✔✔✔ § gh stack modify
✗ uncommitted changes in working tree
Commit or stash your changes before running modify

It makes no sense to commit/stash files which are "untracked".

[chaleecat]

1. Can we get more details besides Pull Request is not mergeable on the UI?
2. Is it possible to use the Stack Feature to merge with rebase option when the org has dismiss_stale_reviews_on_push: true and require_last_push_approval: true set?

[thezuliano]

It would be nice if the /pulls page renders a new kind of row for stacked PR's, representing the entire stack, to avoid mixing them with other separated PR's:

[facundomdelp]

When the stack is too long, it would be nice to center the scroll in the current PR!

[ridler]

Bug report: stack squash-merge fails with false "approving review required", and the web UI hangs silently

Summary

Merging a multi-PR stack fails with a repository rule violation claiming no approving review exists, even though every PR in the stack is approved by a reviewer with write access. In the web UI, the green "Squash and merge stack" button just spins forever and surfaces no error at all. The gh stack merge CLI at least returns the (incorrect) error text.

Environment

• gh version: 2.97.0 (2026-07-31)
• gh stack extension: github/gh-stack v0.1.0
• OS: macOS 26.5.2
• Repo: private org repo, main protected via an organization ruleset
• Merge method: squash (only squash is allowed by the ruleset)

Relevant main ruleset (pull_request rule)

required_approving_review_count: 1
require_code_owner_review: true        (CODEOWNERS file is effectively empty)
require_last_push_approval: false
dismiss_stale_reviews_on_push: false
required_review_thread_resolution: true
allowed_merge_methods: ["squash"]

No required status checks are configured on the ruleset.

Stack shape (4 PRs)

main
  <- #A  (base: main)
    <- #B
      <- #C
        <- #D  (tip)

Repo state at merge time (verified via GraphQL API)

For every one of the four PRs:

• reviewDecision: APPROVED
• mergeStateStatus: CLEAN, mergeable: MERGEABLE
• Two APPROVED reviews, each on the PR's exact current head SHA, both from users with write (role_name: write) and MEMBER association
• 0 unresolved review threads

What happens

Web UI: "Squash and merge stack" button turns green/enabled, click spins indefinitely, no error, nothing merges.

CLI:

$ gh stack merge <tip> --squash --yes
Merging #A, #B, #C, #D into main via squash...
✗ merge failed: Repository rule violations found

At least 1 approving review is required by reviewers with write access.

Stack merges are atomic, so nothing was merged.

Things I tried that did NOT fix it

• Had a second write-access reviewer re-approve the bottom PR → same error.
• Had that reviewer re-approve all four PRs (confirmed APPROVED on each current head SHA) → same error.

The approval requirement is demonstrably satisfied on every PR, so the atomic stack merge appears to be evaluating approvals against something other than the current PR heads (possibly simulated post-squash commits generated during the cascading rebase).

Workaround and its serious side effect

Merging a single PR at a time works for the bottom PR:

$ gh stack merge <bottomPR> --squash --yes
✓ Merged #A into main

But immediately after the bottom PR lands, GitHub retargets the next PR (#B) onto main and dismisses its existing approvals (reviewDecision flips APPROVED → REVIEW_REQUIRED) even though dismiss_stale_reviews_on_push: false and the PR head SHA was not rewritten. It also becomes CONFLICTING against the freshly squashed commit. So the one-at-a-time workaround forces re-review and re-CI on every remaining PR — which defeats the primary purpose of stacked PRs.

Impact

The whole-stack merge path is unusable when any branch protection / review rule is active (which is essentially every real repo), and the only workaround reintroduces exactly the repeated re-review churn stacks are meant to eliminate. The silent, error-less hang in the web UI makes this very hard to diagnose without dropping to the CLI.

Expected behavior

1. The atomic stack squash merge should evaluate required approvals against each PR's current head (which are approved), not fail with a false "no approving review" error.
2. The web UI should surface the same rule-violation error the CLI returns instead of spinning silently.
3. Landing a lower PR in a stack should not dismiss approvals on the retargeted upper PRs when dismiss_stale_reviews_on_push is false and the upper PR's head is unchanged.

[ridler]

that said, I'm very excited for this feature. thank you for prioritizing it 😄 once it's fully functional, I think it'll be a game-changer for productivity

[nilsandrey]

I would like to be able to specify the Squash commit title and content.

[katie-greenboard]

I wish I could copy the stack more easily to send to my slack channel for review

[mgattozzi]

Not being able to insert a PR into the middle of the stack is incredibly frustrating. Especially when a coworker asked me to split a PR up even further. You CAN do this today, but you essentially delete the stack relink and make a new one then push. It's not easy to do "just insert this PR here" which when using jj is a super easy operation (not git lol). Insert change set between two commits in the stack add another bookmark push done.