stack submit reports success (push + PR creation) without actually doing either, when origin remote is an old/renamed repo name

從 gh stack submit 入口開始，使用 issue 中的命令和 git ls-remote 檢查來重現 origin 重新命名的情況。沿著 GitHub 解析路徑追蹤 push 和 PR 建立的結果，並將它們與規範 repository 和工作 repository 的情況進行比較。完成的標準是：失敗的操作回傳錯誤，且無法產生聲稱已建立分支和 PR 的成功輸出。

Environment

• gh version 2.96.0 (2026-07-02)
• gh-stack v0.1.0
• macOS/Linux (bash), two sibling repos in the same GitHub org, one hit the bug and one didn't with the exact same command sequence

Summary

gh stack submit printed full success output — branches pushed, 3 PRs created, a "Stack #478" created — but none of it actually happened on GitHub. The branches were never updated on origin, and no PRs existed anywhere I could find them. A second repo in the same session, using the identical workflow, worked correctly.

Repro shape

• Repo A (worked correctly): plain repo, origin is the canonical name of the repo on GitHub.
• Repo B (bug): origin remote (git@github.com:<org>/<old-repo-name>.git) is an old/renamed name — GitHub transparently redirects gh api repos/<org>/<old-repo-name> and gh repo view to the current canonical name. The canonical repo also happens to carry stale fork/parent metadata pointing at an unrelated third repo (from some past history), though I'm not sure that part is relevant.

Steps, same in both repos:

gh stack init --base <trunk> branchA branchB branchC   # adopts 3 existing local commits, one per branch
gh stack submit

In Repo A, gh stack submit output:

Checking stack state...
Pushing to origin...
✓ Created PR #N1 for branchA
✓ Created PR #N2 for branchB
✓ Created PR #N3 for branchC
✓ Stack created on GitHub with 3 PRs (stack #N4)
✓ Pushed and synced 3 branches

...and this was true — git ls-remote --heads origin showed the branches updated, and gh pr view N1 etc. resolved to real, correctly-based PRs.

In Repo B, gh stack submit printed the exact same shape of success output (different PR numbers), but:

• git ls-remote --heads origin afterward showed the three branches unchanged — branchB (the one branch that existed before stack init, now rewritten to a different commit locally) was still pointing at its old pre-rewrite SHA on origin. branchA and branchC didn't exist on origin at all.
• The claimed PR numbers didn't correspond to any real PR: gh pr view <N1> against the repo (by its canonical resolved name, by the old renamed name, and by the stale fork-parent repo) all failed with "Could not resolve to a PullRequest". gh pr list --head branchA (all three variants of repo name) returned [].
• A second, unmodified gh stack submit run reported PR #N1 is up to date / ✓ Stack on GitHub is up to date with 3 PRs / ✓ Pushed and synced 3 branches — again fully green, again not reflecting reality.

Workaround

Plain git push -f origin branchA branchB branchC (outside gh-stack) worked immediately and updated origin correctly. Manually running gh pr create --repo <canonical-name> --base ... --head ... for each of the 3 layers created real, correctly-stacked PRs. After that, gh stack view correctly picked up the manually-created PRs (via head-branch matching, presumably) and rendered a consistent stack — so the local stack metadata itself wasn't corrupted, only submit's push+create step silently no-op'd while reporting success.

Impact

This is a correctness/trust issue rather than a crash: there's no error, no non-zero exit code (that I checked), and no indication anything is wrong — gh stack submit reports the same "everything succeeded" shape whether or not it actually did anything. Anyone scripting around this or trusting the CLI output at face value would believe their PRs are live when they aren't.

Suspected cause

Possibly a repo-resolution issue: pushing/creating against a stale resolved repo identity (following the old→canonical rename, or the stale fork/parent link) that either 404s silently or targets a repo the invoking user doesn't actually have write access to, without the tool checking the actual API response before printing ✓.

Happy to provide more repro detail/logs if useful — this was found mid-task rather than in an isolated repro, so I don't have a minimal standalone case yet, but the shape above (rename + fork-parent metadata) is the one differentiating factor I found between the working and failing repo.