Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Inserting a layer in the middle of a stack requires unstack + link, which permanently drops merged PRs

Open
#382 2 comments 18 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
48/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
github, go
Domain
api, cli

Research direction

Start by reproducing the reported gh stack link and gh stack unstack behavior, then inspect the REST PATCH /repos/{o}/{r}/pulls/{n} limitation and the existing stack membership flow. Done means a mid-stack insertion or lossless rebuild preserves merged PR membership and keeps the full stack history intact.

Written by the indexing model from the issue text.

Description

feature request topic: cli - stack modification
Summary

There is no way to insert a layer in the middle of an already-submitted stack while keeping the stack's merged PRs as members. The only working procedure (unstack + link) moves the still-open PRs into a new stack and leaves every merged PR behind in the old one, which is then closed. The historical grouping of the stack is lost, permanently and irreversibly.

Current behavior

Given a submitted stack S with, bottom to top, one merged PR #1 and open PRs #2 → #3 → #4, and the need to insert a new layer between #2 and #3:

  1. gh stack modify is TUI-only, so it is unusable non-interactively (and it restructures the local stack, not the server-side membership of an existing PR).
  2. Retargeting the base of an existing stacked PR is refused:
    • REST PATCH /repos/{o}/{r}/pulls/{n}HTTP 422 … PullRequest.base is invalid
    • gh pr edit <n> --base <branch>Cannot change the base branch because the pull request is part of a stack
  3. gh stack link only appends to the top (gh stack link <stack#> <new>); it has no position/insert argument, and it rejects arguments that belong to a different stack.
  4. So the only way out is gh stack unstack <S> + gh stack link <bottom> … <top>. unstack (v0.1.0) unstacks the open PRs and leaves the merged #1 in S; S becomes open: false with #1 as its sole member, and #1 cannot be linked into the new stack (rejected as belonging to another stack).

Net effect: a purely structural edit in the middle of the stack silently destroys the association between the merged layers and the layers that are still in flight.

Expected behavior

Either of:

  • Insertion: a way to place a PR/branch at an arbitrary position of an existing stack, e.g. gh stack link --after <pr> / --before <pr> / --position <n>, without tearing the stack down.
  • Lossless rebuild: allow merged PRs to be re-linked into a stack (or have unstack + link carry them over), so the recovery procedure above at least preserves the full history of the stack.
Why it matters

Merged layers are exactly the part of a stack that documents why the remaining layers look the way they do. Keeping them attached is useful today when reading the stack, and it is what would let the web UI group a whole line of work — landed and in flight — under a single stack. Today, any mid-stack restructuring resets that grouping, so long-lived stacks progressively lose their own history.

Environment
  • gh stack version 0.1.0
  • Private repository, stacks enabled.
Dominant language
Go
Stars
1.5k
Forks
73
Avg merge
1d 8h
Merged PRs (30d)
7

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from github/gh-stack

All issues in github/gh-stack

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.