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 😄

[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!

[victorDigital]

And gh actions status also! 🙌

[imanmahjoubi]

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?

[justinoboyle]

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")

[alvis]

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

[fgr-17]

+1 yes totally. Also showing CI status completion would be great

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

[theophanemayaud]

Yeah same, seems buggy !

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

[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?

[ckhall]

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

[gilescope]

unstack should be a green button with text.

[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

[stevehipwell]

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.

[torarnv]

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! 😊

[stevehipwell]

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.

[MichaelChirico]

+100 to this. I can't believe this wasn't solved before initial release. This should be P0.

[jglick]

github/gh-stack#18 (comment)

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

[kyle-query]

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.

[beakrtobi]

It's also annoying when I try to make a stack of PRs into dev and someone else is making a PR from dev into some-other-branch. The auto detect now only lets me create a stack that includes the dev --> some-other-branch PR.

[nalvelo]

EDIT: Seems there is a phased rollout, as we now have support!

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.

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

[seanmsmith23]

Would love an update here.

[JarredAllen]

My repo with a merge queue just got stacked PRs support today, not sure if everyone has it or if they're doing a staggered rollout.

[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

[kyle-query]

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.

[danilofuchs]

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

[imanmahjoubi]

Thank you for the feedback! Sharing this with the team

[chrismikehogan]

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.

[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

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

[pavel-mikula-sonarsource]

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.

[imanmahjoubi]

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

[Maxr1998]

@imanmahjoubi can we expect a timeline on when this is fixed? This has bitten our team multiple times already, and I'm honestly surprised this bug even went into production considering the main responsibility of GitHub is managing commits correctly…

[thomass-dev]

The "author/email address" bug is still there as of today.

[jheffernan-il]

I ran into an issue using stacks + merge queues + automatically delete head branches. Here's a write up from claude:

---

Merge queue partial-merge closes the next stack layer: automatic base change stops one hop short of main

Summary. When a stack is merged through a merge queue and the queue merges only a lower prefix of the stack, the first unmerged layer gets closed. GitHub's automatic base change moves it one hop to the merged PR's declared base, but that base is a sibling stack branch deleted in the same sweep, and a PR whose base branch is deleted is closed. Seen twice in two weeks on our repo (gh-stack 2026-09 builds, squash merge queue on main).

Repro (from the timeline of our PR #1095, 2026-09-05, all times UTC).

1. Six-layer stack, each PR's base is the previous layer's branch. Enqueued the whole stack with gh stack merge at 19:44:35. Six merge_group runs start in parallel.
2. Queue config: squash, ALLGREEN, min entries to merge 1, build limit 12. Checks finished out of order (layer 3 at 19:54, layer 2 at 19:55, layer 1 at 19:57:36, layer 4 at 19:57:40).
3. 19:57:40 — layers 1–3 become an all-green prefix and merge; their head branches are auto-deleted.
4. 19:57:41 — AutomaticBaseChangeSucceededEvent on layer 4: oldBase = layer 3 branch, newBase = layer 2 branch (layer 3's declared base), not main.
5. 19:57:42 — BaseRefDeletedEvent (layer 2 branch), ClosedEvent, RemovedFromMergeQueueEvent reason manual on layer 4. Layers 5 and 6 are dequeued (reason manual) but stay open because their bases still exist.

The earlier occurrence (2026-09-02) was the same shape but the dequeue reason was merge_conflict, so the exact ordering between retarget, deletion and closure varies.

Expected. Either the automatic base change should cascade through merged-and-deleted stack branches until it reaches a branch that still exists (main), or stack layers enqueued into main's queue should be retargeted to main when their downstack merges, before any head branch is deleted. Alternatively the stack feature could delete merged head branches top-down after retargeting, so the one-hop retarget never lands on a doomed branch.

Recovery is awkward. PATCH /pulls/N state=open fails while the base is gone, so we have to re-push the deleted base branch from a local SHA, reopen, then gh stack unstack (base change is refused with "part of a stack" otherwise), PATCH base=main, rebase and force-push the remaining layers, and gh stack link them into a new stack number. A gh stack sync that could repair a closed layer, or a way to retarget a stacked PR without unstacking, would help a lot.

Also worth noting: gh stack merge --help says the merge is all-or-nothing, but with a merge queue on the base that guarantee does not hold, since the queue merges any all-green prefix as soon as it exists.

---

My current workaround is to disable "automatically delete head branches" but would love a fix here

[nkuba]

We hit the same thing. Our queue uses the MERGE method, and we built the stack in the GitHub UI. The layer above the merged prefix got the one-hop retarget onto a branch that was deleted in the same second, then closed with the same "manual" removal reason. Timeline here: https://github.com/orgs/community/discussions/201439#discussioncomment-18383595

[hobbeswalsh]

We're seeing the same problem with our merge queue + PR stacks of more than 4/5 PRs.

[YikChingTsui]

Previously I faced this bug: https://github.com/orgs/community/discussions/201439#discussioncomment-18048036

Now, it seems like they changed the behaviour to not automatically rebase PRs up on the stack if the one below it was merged. In fact, it seems like there's no way to manually switch the base branch of the PRs above the stack. So after merging only PR A to dev, PR B is stuck targeting PR A. The only workaround is to unstack the entire thing, then switch base branch of PR B to dev.

Surely this has to be the wrong behaviour? At that point, why even allow merging intermediate PRs on the stack if all the PRs above get stuck in limbo.

(I suppose my bug above is solved in the sense that it massively delays the ability to switch the base branch of PR B and merging. But this defeats the whole point of stacked PRs for me.)

To reiterate

My use case is to have distinct but slightly coupled work stacked on top of each other. For example, refactoring done in PR 1 can be used by PR 2 stacked on top of it. But, I want to merge all the individual PRs separately. The one-click merge all button merges only the top PR (which technically does merge all the PRs below it, but the branch only has 1 merge commit, not 1 for each PR)

[AlexisJacob1]

Context

We use gh stack to manage stacks of dependent PRs. On our repos, a required check on the protected branch is handled by an external CI system (Azure DevOps, via its GitHub Checks integration) — not GitHub Actions.

Problem

1. All PRs in the stack are approved, and all checks (including the external Azure DevOps check) are green.
2. I run gh stack merge to merge the whole stack.
3. The first PR in the stack gets merged. GitHub automatically retargets/rebases the following PRs onto the new base, which invalidates their existing checks and re-triggers the Azure DevOps pipeline on each of them.
4. Since this check is owned by an external system, the new result isn't reported back to GitHub instantly (it depends on the pipeline's run time).
5. gh stack immediately tries to merge the next PR in the stack, sees that the required check isn't "success" yet (it's pending, or briefly missing right after invalidation), and fails.
6. Result: the stack merge stops with an error partway through, and the external pipeline has to be manually re-triggered on the remaining PRs before the merge can be resumed.

Expected behavior

After merging a branch that re-triggers required checks on the following branches in the stack, gh stack merge should wait/poll for those checks to come back to "success" (with a reasonable timeout and a clear status message while waiting), instead of failing immediately just because the check isn't already green at the moment it's checked.

This mirrors what we'd get by manually waiting between each merge — gh stack merge could do that for us, since that's the whole point (imo) of automating the stack merge.

Additional context

The check in question is an Azure DevOps pipeline triggered through the GitHub Checks integration (not GitHub Actions), so its turnaround time is outside gh/GitHub's control — but the behavior observed (checks invalidated then re-triggered by the automatic retarget after an intermediate merge) would likely be the same with any slow external check.

[AlexisJacob1]

This looks like the same root cause as these existing discussions: an internal retarget during the atomic merge invalidates an already-satisfied gate (approval or check) before the merge continues, but applied to an external CI check instead of approvals:

• Stack merge blocked despite all requirements met: evaluator divergence, phantom queued state, latency github/gh-stack#404 (evaluator divergence / latency after
  internal merge operations)
• Atomic stack merge is impossible when a ruleset dismisses approvals on merge-base change github/gh-stack#490 (retarget dismisses approvals mid-merge: same mechanism, applied to required approvals rather than external checks)

[AlexisJacob1]

Found the issue: it was a misconfiguration on the Azure Devops side, sorry

[anantdamle]

Few Feature gaps:
Unable to rebuild a stack when bottom of stack layers is already merged.

Scenario:
There are 3 stacked commits/changes/PRs, the bottom PR is merged.
I want to split the top layer PR into 2 PRs, with a portion of the code to move to another PR that is logically below the top PR.

ISSUES:

1. Missing restacking/ordering command
2. Unstack doesn't work (throws errors: Unstacking not allowed: Pull request #1264 cannot be removed from this stack)

[trianglesis]

It will be nice to have an ability to stack PRs from different repos, in at least one org.
There is a lot of work related to updating the code base in logically different places (each as a separate repo) but with related functionality, like backend + frontend.

[nkuba]

We hit a bug in the stacks preview: a PR sitting in the merge queue was closed instead of merged.

A stack of four, A at the bottom, then B, C, D. Automatic deletion of head branches is on. A reviewer added C to the merge queue, which put A and B in with it. D, above C, stayed out.

Timeline in seconds from the first merge:

+0s A merged into main (base main, head branch a)
+1s B merged (base recorded as branch a, head branch b)
+2s branch a deleted
+2s C AutomaticBaseChangeSucceededEvent, oldBase branch b, newBase branch a
+3s C BaseRefDeletedEvent, baseRefName branch a
+3s C ClosedEvent
+3s C RemovedFromMergeQueueEvent, reason "manual"
+4s branch b deleted

The retarget moved C one hop up, onto A's branch, and that branch was deleted in the same second. The deletion of the new base then closed C. main would have worked, because A and B were merged there already.

Reopening C closed it again within a second. D was fine a few hours later, when its parent merged straight into main.

What would help us:

• The retarget picks a base that still exists, or main.
• A PR in the merge queue is not closed when its base branch is deleted. Dropping it from the queue is fine.
• The removal reason says "manual", but nobody removed it.

[glovek08]

Add a remove branch from stack button when creating a PR stack, next in line becomes the new PR target

[brianlove]

The docs say that a stack's trunk is "usually your repository's default branch, such as main, though it can be any branch, such as a release branch." (emphasis added), but that appears to not be configurable in the web interface.

I had a case where I have a larger/long-running branch (hereafter big-refactor) coming off of main, into which I wanted to merge two PRs. I figured I'd try the stack feature, intending that the trunk of the stack would be big-refactor (as that project still has quite a ways to go before it's ready to be merged into main. However, the stack that the web interface created seems to include main as its trunk, and I did not see any clear mechanism by which to change the trunk to big-refactor.

Maybe this is possible via the CLI tool, but I don't have that set up and so I decided to unstack the PRs and handle things separately. If the trunk branch can actually be any branch, it would be nice if the web interface provided that ability to select/edit the trunk branch.

[michaelbaldry-il]

I've found it really hard to add existing PR/branches to a stack, and to understand the internals, so I know what is possible here - I want to add a branch in between 2 others in the stack, how can I go about getting it in the right state for that? It would be good if you could what position the branch is added, then stacks automatically rebases it (and can tell you upfront that it's not possible because of the commits it contains cause conflicts, etc)

[michaelbaldry-il]

I reordered PRs in a stack with gh stack modify. A few of the PRs were already merged. I rearranged the others - I'm not sure exactly what happened, but I think it removed them and tried to add them again in a different order, which caused the stack to close, because all that was left at one point was merged PRs? Then it failed to write to it because of that maybe?

I had to recreate the stack with just the new PRs and lost the merged PRs from the history

[michaelbaldry-il]

With the gh stack modify I had to reconfigure Terminal.app as shift+up shift+down aren't by default configured to send anything different to the application than bare up and down.

Also gh stack modify TUI isn't so usable for an agent, it would be good to have a way to execute these actions in 1 command

[quacainia]

There is another bug with partially merged stacks, this time around creating a new stack.

Situation

• I made stack #309 with 7 PRs based on feat_branch, I'll call the branches pr_* 1-7
• I merged 6/7
• I deleted the stack manually locally and on github
• I created a new stack gh stack init --base feat_branch pr_8 pr_7
• I manually created the PR for pr_8 while pr_7 already existed
• I ran gh stack link 8 7 --base feat_branch and it told me new stack #339
• I ran gh stack submit

Expected Behavior

I expected github to create my brand new stack remotely as #339 as when I do gh stack checkout it is already listed as #339 and #309 no longer exists.

Actual Behavior

Checking stack state...
? The local stack has been modified. Overwrite the existing stack on GitHub? Yes
⚠ Failed to delete existing stack: HTTP 422: Pull requests #1, #2, #3, #4, #5, #6 cannot be removed from this stack (https://api.github.com/repos/example/example/stacks/309/unstack)

They cannot be removed from the stack because they have already been merged, but likewise I apparently cannot create a new stack with #7 because it was once part of #309 even though it no longer exists officially.

Notes

Note 1: I recognize I could have attempted to modify #309 (which would obviously fail if I had already removed the associated branches pr_1 through pr_6 per my last bug report, but there's a work around), but the point isn't that there is an alternative way that it should have been done. The issue is that an apparently legal set of commands results in unexpected errors.

Note 2: gh stack sync still does work and it does ensure the stack #339 shows up on PRs #7 & #8, but submit does not work.

Note 3: When I'm stuck in this limbo new stack still connected to an old remote stack somehow, gh stack modify is entirely blocked. It says: "✗ a modify was completed but the stack has not been submitted yet Run gh stack submit to push changes and recreate the stack on GitHub" which of course doesn't work because it gives me the Failed to delete message seen above.

[quacainia]

Bug or poorly defined behavior within gh stack link

Situation

I have an existing local stack based off a feature branch feature_branch, and an existing set of PRs, and I want to link them because I manually made the PRs.

I run gh stack link 123 124

Expected Behavior

I would expect that if this is based off of a feature branch already, and the PR 123 also already diffs off of feature_branch then it would keep that as the base.

$ gh stack view
Stack
» change_124 (current)
├ change/123
└ feature_branch

$ gh stack link 123 124
Checking existing stacks...
Looking up PRs for 2 branches...
✓ Created stack with 2 PRs (stack #125)

Actual Behavior

Instead of detecting the existing base of the stack (which does exist locally prior to linking, and the bottom PR already points to the correct feature_branch), it assumes that if --base feature_branch is omitted then I intended to rebase to the default branch (which is wrong).

$ gh stack link 123 124
Checking existing stacks...
Looking up PRs for 2 branches...
✓ Updated base branch for PR #123 (https://github.com/example/example/pull/123) to main
✓ Created stack with 2 PRs (stack #125)

Then, the UI doesn't let me change the base branch back to feature_branch and syncing and submitting doesn't work either (which are their own bugs), so the only solution is to unstack, change the base branch back, restack, and link --base feature_branch, which isn't exactly fun.

Suggested fix

If you wish to assume that the user wishes to link to the default branch then there should at least be a prompt asking what base branch the user intended.

$ gh stack link 123 124
Checking existing stacks...
Looking up PRs for 2 branches...
Set stack base to branch (main): _

[sharkleash]

Would be nice if you could gh stack down from the bottom of a stack and reach the trunk!

essentially the reverse of running gh stack up from the trunk to select which stack you want to jump to :)

[amjedidiah]

Totally something to help my AI-first team handle large PRs with the v2 of our product.
Thanks for this