Squashing and merging a stack is stuck

[mlaccetti]

Before:

After:

I've been stuck looking at these spinners for hours. Nothing is merging. I've cancelled and retried a few times; no luck.

[ace22b]

Same issue with rebase for me.

[andykenward]

Are signed commits required on your repos? I'm having the same issue.

[yannickgloster]

Running into the same issue in our repo as well

[borfast]

My repo does not require signed commits (it's the single one in the org like this, I believe).

The one outstanding thing I can think of is that the stack is based off a commit that is no longer the tip of main, and I'm trying to rebase + merge the stack without updating it first (because I don't want the approvals I have to be dismissed).

[nemith]

I've had the same problem. My repo doesn't require signed commits.

[yannickgloster]

Getting a new error on this now when I go to merge, with no explanation on why it's not mergable

[wolszews]

Getting a new error on this now when I go to merge, with no explanation on why it's not mergable

Same here. First day trying to use GH Stacked PRs and everything works fine but merge'ing (Squash and merge stack)

[MelDommer]

Getting a new error on this now when I go to merge, with no explanation on why it's not mergable

@yannickgloster @wolszews

If you have "require approval of the most recent reviewable push" setting on, this will always happen.

I turned that off then merging the entire stack worked.

[borfast]

If you have "require approval of the most recent reviewable push" setting on, this will always happen.

I turned that off then merging the entire stack worked.

But that defeats one of the purposes (the main one?) of this stacking feature. If we still have to do the reapproval dance after every merge-and-rebase, then we don't really need a stacked PRs feature because we can just continue doing that manually, right?

[MelDommer]

I'm just saying that if you want to be able to merge multiple from a stack, you have to turn that setting off.
When you merge one in, the other HAS to rebase onto the latest. This must trigger that setting because it is now considered a new reviewable push. I'm not saying it is right. Ideally, it would detect that this is a stack merge happening and bypass it. 🤷

I'm just spreading the message. I was getting the same errors trying to merge a stack. Turned that setting off, and it worked fine. Of course I turned it right back on 🤣

[FrkAk]

Same problem, we have stack with everything ready, but both squash or merge does not work.

[sassomedia]

Luckily, for us it didn't get stuck when trying to merge the stack. However, it only merged the first (bottom) PR, then returned to "Ready" status for the other PRs.

Since only one PR got merged, the "Rebase Stack" button became available again, but upon trying to rebase, it reported conflicts. Yet, there were no conflicts, as a local gh stack sync rebased fine without issues. After the sync, the PRs were ready to merge again, but seemingly only one at a time. - Stack mergeing does not seem to work at this time.

[sassomedia]

I think I know what the issue is, at least in our repo setup. We squash our PRs when merging them into the main branch.

What GitHub tries to do is merge-squash every PR in sequence, from the first to the last. The first one is always successful, but then it fails on the second one, because now there are conflicts. That sort of makes sense, because the history changed. However, a local rebase doesn't actually have conflicts as it properly rebases from front to back.

I believe all they would need to do for a stack to successfully merge-squash is to start from the last branch. It contains all changes from the other branches. So only the last branch needs to be merge-squashed, and all the other ones could be automatically closed.

This is the workaround I currently do once a stack is fully approved:

1. Locally check out a new branch (not part of the stack) git checkout -b combined-stack
2. Squash all commits from the top stack branch into the new branch git merge --squash <TOP_MOST_BRANCH_NAME>
3. Commit, push and create a new PR with the new branch that now contains all changes of the stack
4. Merge(-squash) the PR into main
5. Close the stack manually (close and delete each branch)

[phillip-haydon]

We don’t use squash. We have the default merge commit. It’s still fucked for us.

[skarim]

x-posting from #256

Hey all, thanks for the reports. We've identified a bug where approvals are not being appropriately evaluated when merging a stack of multiple PRs. We're actively investigating and will update when we've released a fix.

In the meantime, you can get around this by merging one PR at a time. I know it's not ideal, but hopefully that will unblock your workflows in the short-term. Appreciate your patience!

[borfast]

@nemith I've been doing the same, praising stacked changes for years, have pestered people to join the preview, and now they're all looking at me and going "is this what you've been selling us as the greatest thing ever? 😒" - not great for my reputation 😅 But also not great because people will think this is the stacked changes experience, they won't want to touch it, and we all end up losing.

[phillip-haydon]

@borfast that's not true as of yesterday, see https://github.blog/changelog/2026-07-30-stacked-pull-requests-are-now-in-public-preview/

I stand corrected. Thank you @alexharri .

You’re wrong. And even if it was closed beta it should be in a better state than it is.

@phillip-haydon I would disagree on the closed beta, since its whole purpose is to start getting feedback while still being able to make big mistakes. Public beta is a different story, and there I would agree that this is definitely not at a level for a public preview. The feature is pretty much broken and not useful, which is not expected of a preview - if it doesn't work, what are people going to preview? 🙂

I’m pretty angry because the people at github obviously have checked out and don’t care about what they deliver.

https://x.com/cassidoo/status/2083210982847910127?s=46&t=gSe7f3HqlOJ1WkvKbrmlnQ

Look at this.

Okay so now that we shipped stacked PRs, what's the next biggest request you have for GitHub to take on?

What the hell is going on inside GitHub. Ship stuff and move on? They don’t care about the customer experience at all.

[TRStarr]

merging one PR at a time

This has caused my stack of 11 PRs to rebase, require re-approval and triggered new builds... now waiting for each build to complete and others to approve.

I am very disappointed in stack PRs considering the amount of hype GitHub have made about this

[WalterWong-Wise]

Hello @skarim, just wondering if there is any update on the fix? Thank you. 🙇‍♂️

[bassman02]

how tf is there not a fix shipped for this yet?? Show stopper for any non-trivial stack

[juliosampaio]

I’m seeing the same problem here :/ Since the public preview started, it hasn’t been working properly.

[nemith]

pretty sure it never worked (branch protection rules around dismissing reviews + stacking). There has been no indication of timeframe to fix either.

The problem is turning off the the protection rules is a non-starter for a lot of companies.

[jothompson-prismhr]

I know I tested it and it worked before I rolled it out for our team to use. Then the next one I tried had issues. So I'm wondering if it has to do with a change to our build to use an Azure DevOps pipeline to doing it in Github Actions.

[phillip-haydon]

I know I tested it and it worked before I rolled it out for our team to use. Then the next one I tried had issues. So I'm wondering if it has to do with a change to our build to use an Azure DevOps pipeline to doing it in Github Actions.

Nothing to do with your use. It’s an issue with incompetent developers at GitHub.

[GuillermoGaete]

Same issue here! Will you fix this in the short term?

[michal-samluk]

I have the same issue.

[RaniAgus]

Same here. And merging one by one doesn't work because it reruns the CI every time and drops PR approvals, so it's not a valid workaround.

[rcarrion2]

I have the same problem. It's a shame.

[joshuastone]

I have this issue as well, which completely eliminates one of the main benefits of stacked PRs as they're unable to merge together atomically via a single merge group in the merge queue.

My basic stacked PR setup

• Two PRs: A and B
• A branches off main, B branches off A (main -> A -> B)
• Linear stack with only one commit each
• Both PRs MERGEABLE outside the queue
• Full stack is capable of fast-forwarding into main with zero conflicts (tested locally)

Observed behavior

• Click the "Enqueue stack (2)" button on PR B → PR B immediately reports conflicts while in the merge queue
• Dequeue the stack → conflict on PR B immediately disappears when outside the queue
• If I don't dequeue the stack, PR A merges and PR B gets ejected

Settings

• require_last_push_approval: false
• required_approving_review_count: 0
• allowed_merge_methods: ["rebase"]

Note that unlike others, my repository doesn't even require approvals or signed commits.

[rayandesplanque]

+1, same for me can't Squash-and-merge, tried twice 🙄

[amartinrelativity]

Is there a plan to fix the "Dismiss stale pull request approvals" issue or will this just be the state?

[JaccoGoris]

The branch protection is what caused this for us. when turning off the approval reqs for PR's it merged immediately.

This setting was turned on on main:
Require approvals
When enabled, pull requests targeting a matching branch require a number of approvals and no changes requested before they can be merged.

and gave this error in the terminal:
✗ merge failed: protected branch 'main' check failed:
At least 1 approving review is required by reviewers with write access.
Stack merges are atomic, so nothing was merged.

both PR's had two approvals by other team members

[abed-daloopa]

Good to know but turning off "Require approvals" on main is a nonstarter for many projects

[Alvov1]

It's not always only "Require approvals". For example, in my case all PRs were approved but the "require up-to-date with main" was stopping the merge

[duncanharris]

Same here

[icebit]

Bro

[priscilaoliveira-nomad]

When do you plan to fix the problem? Because constantly hacking project permissions just to make a feature work is not an option. 🙄

[zboigor]

The feature got pretty useless with the recent bugs

[eraykoschell]

How is this feature available for public preview when such a core part of it doesn't work? 😢

I shall give it more time to bake in the oven before considering trying it again.

[0bill]

same issue for me

[phillip-haydon]

They haven’t contributed to the feature in like 6 weeks. The developers have checked out and don’t care.

MS should just fire all the devs at github and start again because they just don’t care about the product at all.

[tthoma24]

I am usually the first to hop on the M$ bashing train, but to give the devs the benefit of the doubt here, that's only main, there's at least four feature branches they've committed to since then.

[vuon9]

Life still happens in another way for people who don't use gh CLI but only git + GitHub UIs... so I don't think any feature branch of this repo would help because it's only about gh extensions - which is for client side. Their backend (aka server side) bugs caused it.

[TeeThanakit]

Same problem

[ppearyxx]

Will looking forward on the fix.

[ShinRai1090]

It's funny, they fixed the perma spins I suppose as I now see the approval blocking message when I try to merge the stack.

I realized it's the "make approvals stale when new changes are pushed to the branch" rule that's causing the issue here. But fcol! Who is so dumb to not create a way to differentiate between changes brought in through stacks vs changes through independent PRs or manual commits / merges. 🤦🏻‍♂️

Stacks are useless without a way to differentiate between stacks and other changes. And disabling the stale approval rule is not the way, if a dev makes changes the approvals have to go stale for re-review.

[phillip-haydon]

While we wait for stacked PRs to be fixed. The product lead for stacked PRs is busy making more junk features and ignoring stacked PRs.

[shlomie-yaniv]

Following up on @imanmahjoubi's 2026-08-11 update about the fix for squash-merge queues: we still see the false conflict with a rebase merge queue, as of 2026-10-06, and we traced how it happens. In case it helps:

Setup. An organization repository. main is protected by a ruleset with a merge queue: merge method REBASE, build 5, groups of 1–5, ALLGREEN. It requires 1 approval with stale approvals dismissed, and linear history. The stacks are native, linear and rooted on main, and every layer is approved and green before we enqueue.

What happens. In all five attempts between 2026-09-30 and 2026-10-06, only the bottom layer landed per queue pass. The layer above left the queue every time:

Date	Child's removal	When
2026-09-30	The queue UI showed "Merge conflicts" for every child; we removed them by hand	While the parent's group built
2026-10-03	invalid_merge_commit, then stack_out_of_order	17 s after enqueue, before the parent's group run started
2026-10-06 (3 stacks)	merge_conflict	Within one second of the parent merging. The child was retargeted to main in that second and restacked about 5 s later

After the restack, the child's checks run again (about 7 minutes) and a re-enqueue lands it (about 10 minutes). So each extra layer costs about 20 minutes plus someone to re-enqueue it.

Why it happens. We replayed three of these attempts (2026-09-30, 2026-10-03 and the first one on 2026-10-06):

• The rebase queue rewrites the parent's commits even when they already fast-forward onto the group base. The new commits have new SHAs and an identical tree.
• The child's branch still contains the parent's original commits.
• Replaying the child's whole range from main, commit by commit, onto the parent's real merge-group head reproduces each outcome:
  • the parent's original commits become empty commits, which matches invalid_merge_commit;
  • where a later parent commit rewrote a file that an earlier parent commit created, re-applying the earlier commit is an add/add conflict, which matches merge_conflict.
• Replaying only the child's own commits onto the same head is clean every time. The resulting tree is byte-identical to the tree GitHub's automatic restack produces a few seconds later.

So the stack itself is fine. It looks like the child's queue entry is built, or re-checked when the parent merges, from the child's head before the restack. Either of two changes would fix it:

• Build the child's group from the parent's group head with only the child's own commits, as --onto <parent group head> <parent head> would.
• Restack before re-checking the queued children.

The replay script emulates a per-commit rebase with git merge-tree:

#!/usr/bin/env bash
# usage: replay.sh <onto> <range-base> <range-head>
set -u
cur=$1
for c in $(git rev-list --reverse "$2..$3"); do
  p=$(git rev-parse "$c^")
  out=$(git merge-tree --write-tree --merge-base="$p" "$cur" "$c"); rc=$?
  tree=$(printf '%s\n' "$out" | head -1)
  if [ "$rc" -ne 0 ]; then echo "CONFLICT applying $c"; printf '%s\n' "$out" | sed -n '2,12p'; exit 1; fi
  prev_tree=$(git rev-parse "$cur^{tree}")
  cur=$(git commit-tree "$tree" -p "$cur" -m "replay $c")
  if [ "$tree" = "$prev_tree" ]; then echo "empty: $c"; else echo "ok: $c"; fi
done
echo "CLEAN tree=$(git rev-parse "$cur^{tree}")"

• Full range: replay.sh <parent group head> <group base> <child head>. It gives empty commits or the conflict.
• Own commits only: replay.sh <parent group head> <parent head> <child head>. It is always clean.

We have more timelines if they are useful.

[gps035]

Is there a reason this issue wasn't a blocker for GA (let alone preview)? https://github.blog/changelog/2026-10-06-stacked-pull-requests-generally-available

[phillip-haydon]

I don’t think they care. No one working at GitHub has any passion left for development or creating good products. Just collect a payslip.

[tthoma24]

They claim it is fixed:

Approvals stay in place for unchanged code. When an otherwise unchanged stack is updated after its base branch, such as main, moves ahead, Rebase stack now preserves approvals, even in repositories that dismiss stale approvals.

[phillip-haydon]

In the last few days? I’ll have to try again but it wasn’t working Friday last week.