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!

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

[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

[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

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

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

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

[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

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

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

[davhdavh]

Some feedback:

1. When looking at the commits initially, it is hard to find the top
2. There is no clear actions github. we can use to process top/bottom of the stack in a particular way

[simone-panico]

It would help a lot if the overview page grouped each stack into a single entry that can be expanded. Right now it looks a bit chaotic with many PRs

[evert]

It's a bit crazy to me that Github needs to advertise this feature withing github:

<sub>Stack created with <a href="https://github.com/github/gh-stack">GitHub Stacks CLI</a> • <a href="https://gh.io/stacks-feedback">Give Feedback 💬</a></sub>

Why is this not part of UI and now becomes part of issue and commit history unless edited? The noise on github about github keeps increasing. It's a great feature aside from that annoyance though!

[mateo-di]

Hi 👋

Adding info to the squash-merge-stack failures case already reported here:

• We've hit this consistently across three different engineers on our org over ~3 weeks (July 24 → Aug 14), always in the same repo.

Symptom:

• clicking "Squash and merge stack" from the top PR shows the merging spinner for a few seconds, then reverts to the pre-merge state with no visible error.
• The PR event log shows automerge being disabled with "Pull Request is not mergeable," even though every PR in the stack individually shows as mergeable and approved in the UI.
  We have branch protection rules:
• We have branch protection config and think we found a possible contributing factor: our target branch has both classic branch protection (require_last_push_approval: true) and a repository ruleset targeting the same branch (dismiss_stale_reviews_on_push: true).
• GitHub merges overlapping classic-protection + ruleset settings by taking the most restrictive of each, so the effective policy is "dismiss approvals on every push" + "require approval of the latest push."
• Since collapsing/rebasing a stack after a lower PR merges triggers a synthetic push on the PRs above it, this looks like it invalidates their approvals right before the stack-merge mergeability check runs.
• This COULD explain why the UI still shows "approved/mergeable" (stale cached state) but the actual merge attempt fails silently.

Might be worth checking whether the preview's mergeability check is racing against approval dismissal specifically in orgs mixing classic branch protection with rulesets on the same branch 🤔 ?

[spencerf2]

Feature Request:

Add an author_email parameter to the async stack merge endpoint (PUT /repos/{owner}/{repo}/pulls/{n}/merge-async) that applies to each squash commit the merge creates, matching the existing mergePullRequest.authorEmail. Expose it as --author-email/-A on gh stack merge.

Use case:

Engineers on personal GitHub accounts who want work commits attributed to their company email. gh pr merge --author-email handles this today, and many engineers prefer using their personal GitHub over maintaining a separate work-only account. Stacks drop the option: merge-async has no authorship field, and the legacy merge mutation/endpoint rejects stacked PRs. Currently, merging a two-PR stack from the web UI commits both under a users.noreply.github.com or personal address.

For now, merging each PR manually with gh pr merge -A works as a workaround, but it gives up the awesome, atomic, all-or-nothing stack merge!

[whizzzkid]

Stacked PRs, especially with squashed merges is entirely broken. The UI does not reflect the errors either. I get better error messages locally:

✗ merge failed: Repository rule violations found

Waiting on 1 reapproval from someone other than the last pusher. Reviews from <reviewers> are stale because they were submitted before the merge base changed.

this should have been accounted for, or should not be enabled for repos where these settings are applied.

[danielkatfavor]

https://github.com/orgs/community/discussions/204981

I filed this today and it seems like a real gap in the product. The feedback is:

Add an org/repo setting to disable Stacked Pull Requests

🏷️ Discussion Type

Product Feedback

Body

Stacked pull requests do not need setup. The feature works for a repo as soon as a user makes a stack. Some orgs want to turn this off.

Please add a setting to disable Stacked Pull Requests at the organization level or the repository level.

Reasons for this request:

1. Stacked PRs increase CI cost — each layer in a stack triggers its own full CI run, multiplying job count for what is one logical change.
2. We want changes to land one at a time, in full, rather than as parallel in-review layers.

Current workaround and its gap:

We already restrict CI to only run on pull requests that target our mainline branches. When we tested this against a stack, a CI job ran anyway on an intermediate PR that did not target a mainline branch — the stack bypassed our restriction. Without a real disable option, we have no reliable way to stop CI from running on these PRs.

Request:

• Add a toggle (for example under Organization Settings → Code, planning, and automation, or Repository Settings → General) to turn off Stacked Pull Requests for a repo or org.
• When off, block the creation of new stacks and show a clear message to the user.

[masonreed11]

Sounds like a genuine UI bug, especially since it’s consistently reproducible from the “Involves me” page. report it with the browser/version and exact steps to reproduce, as that should make it easier for GitHub to trace. Hopefully it gets picked up quickly since the rest of the experience sounds solid.

…

On Tue, Aug 11, 2026 at 11:19 AM Adrian Schmidt ***@***.***> wrote: Great feature! There seems to be no ruleset override available on stacked PRs though? On a non-stacked PR, I can check a box to "Merge without waiting for requirements to be met (bypass rules)", but on stacked PRs there is no such option. — Reply to this email directly, view it on GitHub <#201439?email_source=notifications&email_token=CHUCEBYFNDAJEPYBHPIMEGD5JLCGZA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZZG4ZDEMZYUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#discussioncomment-17972238>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/CHUCEB4FBREP2XECOTKSQ3D5JLCGZAVCNFSNUABIKJSXA33TNF2G64TZHMZTAMJVG4ZTGNBUHNCGS43DOVZXG2LPNY5TCMBUGAYTCMRWUF3AE> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/CHUCEB6IADQ2P3UCMSZXM635JLCGZA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZZG4ZDEMZYUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSVGM33PORSXEX3JN5ZQ> and Android <https://github.com/notifications/mobile/android/CHUCEB3K2CXF2ZEULW5AXLT5JLCGZA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZZG4ZDEMZYUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSXGM33PORSXEX3BNZSHE33JMQ>. Download it today! You are receiving this because you commented.Message ID: ***@***.***>

[demostheneslld]

Confirmed stacked-PR readiness bug involving duplicate GitHub Actions runs for the same head commit.

Setup:

• 7-layer native GitHub stack; affected PR was at position 5.
• Branch protection required 3 Actions checks, strict status checks, and conversation resolution; 0 approving reviews were required.
• A workflow using concurrency with cancel-in-progress produced two runs for the same SHA in the same second.
• The lower database-ID run completed successfully.
• The higher database-ID run was cancelled and updated later.
• All required checks appeared successful; the affected PR was mergeable, had no unresolved threads, and needed no rebase. Every other stack layer was clean.

Observed: the affected layer remained blocked / stack not ready.

Confirmed workaround: rerunning the higher-ID cancelled workflow changed the PR from blocked to clean without any branch or stack changes.

This suggests stack readiness may select the later cancelled check suite even when another suite on the exact head SHA satisfies every required check. The normal PR check presentation showed green, obscuring the blocker.

Expected: stack readiness should accept successful required checks on the current head, or expose the exact workflow run/check causing the blocked state.

Environment: gh 2.96.0, gh-stack v0.1.0. The repository is private, so links and identifiers are intentionally omitted.

[LecrisUT]

We have a rather more complex case, which I am not even sure if without stacked PRs we are abusing some undocumented bug.

Basically we have 2 branch rule sets that apply to the same main branch:

• Rule for all
  • Require some basic set of rules like no force push, resolved PR comments etc.
  • No bypass is allowed from anybody
• Rules that privileged team can bypass
  • More soft rules like PR checks, reviewer approval and such are here
  • A specific team can bypass if forced

This setup, at least to our testing works fine, i.e. the rules seem to be merged together (we don't know what would happen if there were duplicate items in both), and the privileged team can force bypass some of the checks if the other checks like resolved PR comments is satisfied. But on stacked PRs, this is no longer the case. At the very beginning I believe the button was there, but now it is completely grayed out, as if the checks are merged together without any of the bypass rules.

[YikChingTsui]

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)

The workaround is to manually merge each PR. However, when merging PRs like this in rapid succession, the CI for the unmerged PRs can fail:

Run actions/checkout@v4 29s
Run actions/checkout@v4
Syncing repository: xxx/xxx
Getting Git version info
Temporarily overriding HOME='/home/runner/work/_temp/2eb1919d-1215-46af-8515-f15f06621be2' before making global git config changes
Adding repository directory to the temporary git global config as a safe directory
/usr/bin/git config --global --add safe.directory /home/runner/work/xxx/xxx
Deleting the contents of '/home/runner/work/xxx/xxx'
Initializing the repository
Disabling automatic garbage collection
Setting up auth
Fetching the repository
  /usr/bin/git -c protocol.version=2 fetch --no-tags --prune --no-recurse-submodules --depth=1 origin +refs/pull/551/merge:refs/remotes/pull/551/merge
  Error: fatal: couldn't find remote ref refs/pull/551/merge
  The process '/usr/bin/git' failed with exit code 128
  Waiting 16 seconds before trying again
  /usr/bin/git -c protocol.version=2 fetch --no-tags --prune --no-recurse-submodules --depth=1 origin +refs/pull/551/merge:refs/remotes/pull/551/merge
  Error: fatal: couldn't find remote ref refs/pull/551/merge
  The process '/usr/bin/git' failed with exit code 128
  Waiting 11 seconds before trying again
  /usr/bin/git -c protocol.version=2 fetch --no-tags --prune --no-recurse-submodules --depth=1 origin +refs/pull/551/merge:refs/remotes/pull/551/merge
  Error: fatal: couldn't find remote ref refs/pull/551/merge
  Error: The process '/usr/bin/git' failed with exit code 128

PR 550 is the first PR and PR 551 is the second PR stacked on top of the first. This is the CI run for PR 551, after merging PR 550, and probably after merging PR 551 as well (I merged the 2 PRs individually in rapid succession, probably before the checkout task started). This CI run was started because of the automatic rebase after merging PR 550

[andrejpodzimek]

Yet another error message completely detached from reality:

PullRequest.base is invalid
✗ Cannot create stack: Pull requests must form a stack, where each PR's base ref is the previous PR's head ref

This thing is just not ready for everyday use.

[muffato]

Similar to https://github.com/orgs/community/discussions/201439#discussioncomment-18048036 , I was using stacked PRs to indicate changes that depend upon one another.
I was hoping I could get all PRs merged individually with one click, but that is not implemented yet. I had to go and merge all PRs one by one while waiting for all the CI to recompute, which is a waste of time. I would have liked all merge commits to be added at once with one click.

[gmedori]

I'm not sure if this has been requested already, but it would be great to be able to edit metadata (reviewers, labels, etc.) for the entire stack with a single command.

Also, for scripting purposes, some subcommand called list for enumerating the branches in a stack from bottom to top would also be nice. If I had such a list subcommand, I could have implemented the bulk metadata-editing myself with a simple for-loop in my shell.

[tgregory-block]

I would really like an equivalent to graphite's split command, where a stack can be created by taking a single feature branch with multiple commits, and splitting those commits out into separate stacked branches