Inserting a layer in the middle of a stack requires unstack + link, which permanently drops merged PRs
まだ誰も着手していません。
評価
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 初心者へのやさしさ
- 48/100
調査の方向性
まず、報告された gh stack link と gh stack unstack の動作を再現し、次に REST PATCH /repos/{o}/{r}/pulls/{n} の制限と既存のスタックメンバーシップのフローを調査します。スタックの途中への挿入またはロスレスな再構築によって、マージ済み PR のメンバーシップが保持され、スタック全体の履歴が完全な状態で維持されれば完了です。
索引モデルが issue の本文から書いたものです。
説明
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:
gh stack modifyis TUI-only, so it is unusable non-interactively (and it restructures the local stack, not the server-side membership of an existing PR).- 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
- REST
gh stack linkonly 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.- 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#1inS;Sbecomesopen: falsewith#1as its sole member, and#1cannot 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+linkcarry 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.
- 主要言語
- Go
- スター
- 1.5k
- フォーク
- 73
- 平均マージ
- 1日 8時間
- マージ済み PR(30日)
- 7
コントリビューションガイド
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
github/gh-stack のほかの issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 85/100
-
難易度 1/5 1時間未満 初心者へのやさしさ 92/100
-
feature request topic: cli - general
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
-
feature request topic: auto-merge
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
-
bug topic: docs
難易度 1/5 1時間未満 初心者へのやさしさ 68/100
github/gh-stack の issue をすべて見る
似ている issue
-
textual definition
難易度 1/5 1時間未満 初心者へのやさしさ 90/100
geneontology/go-ontology#32653 ·
-
難易度 1/5 1時間未満 初心者へのやさしさ 75/100
-
needs design
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
-
Priority/High ready-for-agent Severity/Major Type/Bug
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
-
難易度 2/5 1〜3時間 初心者へのやさしさ 70/100