Inserting a layer in the middle of a stack requires unstack + link, which permanently drops merged PRs
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 5/5
- Thời gian dự kiến
- Hơn một tuần
- Mức phù hợp với người mới
- 48/100
Hướng nghiên cứu
Bắt đầu bằng cách tái hiện hành vi đã được báo cáo của gh stack link và gh stack unstack, sau đó kiểm tra giới hạn của REST PATCH /repos/{o}/{r}/pulls/{n} và luồng membership của stack hiện có. Công việc được hoàn tất khi việc chèn vào giữa stack hoặc rebuild không mất dữ liệu bảo toàn membership của các PR đã merge và giữ nguyên toàn bộ lịch sử của stack.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
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.
- Ngôn ngữ chính
- Go
- Star
- 1.5k
- Fork
- 73
- Merge trung bình
- 1 ngày 8 giờ
- Pull request đã merge (30 ngày)
- 7
Hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của github/gh-stack
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 85/100
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 92/100
-
feature request topic: cli - general
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
-
feature request topic: auto-merge
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
-
bug topic: docs
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 68/100
Tất cả issue của github/gh-stack
Issue tương tự
-
area/dev-productivity area/disaster-recovery area/ipcei kind/enhancement
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 85/100
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
-
kind/bug status/0-triage
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
-
🤔 refinement needed
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
equinor/radix-operator#1979 ·