gh stack link --remote <fork> queries the fork’s parent repository
還沒有人認領這個 Issue。
評估
- 難度
- 3/5
- 預估耗時
- 1-2 天
- 新手友好度
- 68/100
- Issue 類型
- 缺陷
- 描述清晰度
- 基本清楚
- 活躍度
- 活躍
- 技術堆疊
- git, github, go
研究方向
先在多遠端 fork 設定中重現 gh stack link --base main --remote fork --open <first-pr> <second-pr>，然後檢查儲存庫解析和 .git/gh-stack 狀態。完成標準是該命令使用 fork 端點，且衝突的儲存庫訊號會在 API 請求之前以明確的選擇錯誤失敗；為此情境新增一個回歸測試。
由索引模型根據 Issue 內容生成。
描述
Summary
In a fork clone with separate upstream and fork remotes, gh stack link --remote fork queries the stack API for the upstream parent repository instead of the selected fork.
This prevents linking existing PRs when access to the parent is restricted, even though the authenticated user can access the fork and all PRs being linked have both their base and head repositories in the fork.
This appears related to #381, but that report covers gh stack submit selecting origin in a multi-remote clone. This reproduction covers gh stack link, has no origin remote, and shows the extension selecting a fork's parent despite an explicit --remote, remote.pushDefault, and gh-resolved repository.
Environment
gh version 2.100.0 (2026-09-03)gh stack/github/gh-stackv0.1.1- Repository:
<fork-owner>/<repository>, a fork of<upstream-owner>/<repository> - Two existing PRs whose base and head repositories are both the fork
Repository configuration
$ git remote -v
fork [email protected]:<fork-owner>/<repository>.git (fetch)
fork [email protected]:<fork-owner>/<repository>.git (push)
upstream [email protected]:<upstream-owner>/<repository>.git (fetch)
upstream no_push (push)
$ git config --get remote.pushDefault
fork
$ git config --get remote.fork.gh-resolved
<fork-owner>/<repository>
$ gh repo set-default --view
<fork-owner>/<repository>
The local .git/gh-stack state was initialized with the parent repository despite this configuration:
{
"schemaVersion": 1,
"repository": "github.com:<upstream-owner>/<repository>"
}
Steps to reproduce
-
Clone a GitHub fork with one remote for the fork and a separate fetch-only remote for its parent. There is no
originremote. -
Set the fork as the push/default GitHub repository:
git config remote.pushDefault fork git config remote.fork.gh-resolved <fork-owner>/<repository> -
In the fork, create two open PRs intended to form a stack. Both PRs have base and head repositories equal to
<fork-owner>/<repository>. -
Run:
gh stack link --base main --remote fork --open <first-pr> <second-pr>
Actual behavior
The extension calls the parent repository's stack endpoint and fails:
Checking existing stacks...
failed to list stacks: HTTP 403
(https://api.github.com/repos/<upstream-owner>/<repository>/stacks?per_page=100&page=1)
The authentication failure is expected for that parent repository. The unexpected behavior is querying the parent at all.
Expected behavior
gh stack link --remote fork should query and mutate stack metadata in <fork-owner>/<repository>, matching:
- the explicitly selected remote;
remote.pushDefault;- standard
ghrepository resolution; and - the base/head repository of every PR passed to
--open.
If these signals disagree, the extension should fail before making an API request and report which repository needs to be selected.
Controls
The correct fork endpoint is accessible with the same authentication:
gh api 'repos/<fork-owner>/<repository>/stacks?per_page=100&page=1'
# HTTP 200
Running the same link command from a temporary Git repository whose only remote is <fork-owner>/<repository> succeeds:
Created stack with 2 PRs
This isolates the failure to repository resolution in the multi-remote fork clone rather than authentication, PR shape, or stack creation.
Impact
gh stack linkcannot be used normally in this fork/multi-remote layout.- Users may receive misleading authentication errors for a repository they did not select.
- Where the user has access to both repositories, the command may read or write stack metadata in the wrong repository.
Workaround
Run gh stack link from a temporary repository configured with only the fork remote. This is error-prone and loses the normal relationship with the working clone.
Related
- #381 reports the likely shared repository-resolution defect for
gh stack submit. - #461 reports stale fork/parent metadata affecting
gh stack submitafter a remote rename.
If maintainers consider link covered by #381, I am happy for this to be closed as a duplicate; the additional reproduction may still be useful for a regression test.
- 主要語言
- Go
- 星號
- 1.6k
- 分支
- 78
- PR 合併指標
- 30 天內沒有已合併 PR
環境準備
- 沒有 Dockerfile 或 Docker Compose 檔案
- 沒有 Pull Request 範本
- 閱讀貢獻指南
從這裡開始
- 先讀完整個 Issue，再讀專案的貢獻指南。
- 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
- Fork 儲存庫，在一個分支上完成修改。
- 送出 Pull Request，並在描述裡引用這個 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
相似的 Issue
-
難度 2/5 1-3 小時 新手友好度 68/100
維護者通常 1 天內回覆
-
bug needs-acceptance wg/developer-experience-ecosystem
難度 2/5 1-3 小時 新手友好度 88/100
vllm-project/semantic-router#4480 ·
維護者通常 1 天內回覆
-
area/docs kind/documentation priority/backlog triage/accepted
難度 2/5 1-3 小時 新手友好度 88/100
lexfrei/cloudflare-tunnel-gateway-controller#943 ·
維護者通常 1 天內回覆
-
bug
難度 2/5 1-3 小時 新手友好度 75/100
keyxmakerx/Chronicle#967 ·
維護者通常 1 天內回覆
-
bug
難度 2/5 1-3 小時 新手友好度 65/100
DaoCloud/DaoCloud-docs#7446 ·
維護者通常 1 天內回覆