**My work entry becomes permanently unusable and un-removable when a PR's bas...
还没有人认领这个 Issue。
评估
- 难度
- 3/5
- 预计耗时
- 1-2 天
- 新手友好度
- 65/100
- Issue 类型
- 缺陷
- 描述清晰度
- 描述清楚
- 活跃度
- 活跃
- 技术栈
- git, github, github-actions
调研方向
Look for the code that prepares worktrees and fetches refs, likely in a module handling 'My work' sessions. The fetch command with multiple refspecs is the culprit. Start by searching for 'git fetch' and 'refs/pull' in the codebase. Understand how the app constructs the fetch command when opening a PR. The fix involves modifying the fetch logic to handle missing base branches gracefully, perhaps by fetching refs separately or using a glob pattern. Test by simulating the scenario in a development environment.
由索引模型根据 Issue 内容生成。
描述
My work entry becomes permanently unusable and un-removable when a PR's base branch is deleted
Summary
In the My work view, a merged PR whose head/base branches no longer exist stays listed forever with Session: Unavailable. It can never be opened (worktree preparation fails), and there is no way to remove the entry.
Environment
-
GitHub Copilot app 1.1.23 (
github.exe, Windows) -
git 2.53.0.windows.4
-
Private GitHub.com repo; PR was squash-merged and both source branches were deleted afterwards
Steps to reproduce
-
Have a PR whose base branch exists (works normally at this point).
-
Merge it (squash), then delete the head and base branches.
-
Open My work — the PR is still listed (seen in the
AllandDoneviews). -
Try to open it.
Actual
Worktree preparation runs:
Bash
git fetch --no-write-fetch-head origin \
+refs/heads/<base-branch>:refs/remotes/origin/<base-branch> \
+refs/pull/<N>/head:refs/remotes/origin/pr/<N>
and fails with:
Plain text
fatal: couldn't find remote ref refs/heads/<base-branch>
exit code 128, so the session/worktree can't be created. The row remains in the list with Session: Unavailable, permanently.
Root cause / evidence
-
refs/pull/<N>/headstill resolves after a merge, but a singlegit fetchwith multiple refspecs is all-or-nothing: one missing ref aborts the whole fetch and nothing is written — not even the ref that does exist. Reproduced in a clean temporary clone: exit 128, andgit for-each-refshows zero refs written. -
Fetching only
+refs/pull/<N>/head:refs/remotes/origin/pr/<N>succeeds (exit 0), so the PR ref alone would be enough. -
git ls-remote origin "refs/pull/<N>/*"confirms the ref is still available.
Suggested fix
-
Don't put the base-branch and PR-head refspecs in a single fetch; or
-
treat a missing base ref as non-fatal (fetch the PR ref, continue, and degrade the diff base); or
-
use a glob refspec for the base branch — verified that
+refs/heads/<pattern>/*:refs/remotes/origin/<pattern>/*exits 0 silently when nothing matches, while an explicit missing ref name is a hard error. -
Note:
git fetch --no-error-on-missing-refdoes not exist in git 2.53.0.windows.4, so that isn't available.
No workaround currently exists in the UI
Checked in 1.1.23: right-clicking the row → no context menu; Actions → no menu appears for this item; right-clicking the view tab → only Duplicate / Reorder views (no rename/edit-query/delete). The All view's saved query is empty (catch-all), so the entry is always shown there.
Related
#713 (dismiss/snooze individual items in My work) would give an escape hatch, but the underlying fetch failure is a bug on its own.
| Field | Value |
|---|---|
| App version | 1.1.23 |
| OS | Windows 10.0.26200 |
| Theme | GitHub |
| Path | /chat |
| Tenure | Day 5 (Week 1) |
- 主要语言
- 没有语言数据
- 星标
- 2.1k
- 派生
- 157
- PR 合并指标
- 30 天内没有已合并 PR
环境准备
从这里开始
- 先读完整个 Issue,再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库,在一个分支上完成修改。
- 提交 Pull Request,并在描述里引用这个 Issue 编号。
github/app 的其他 Issue
-
triage
难度 2/5 1-3 小时 新手友好度 70/100
-
难度 2/5 1-3 小时 新手友好度 65/100
-
难度 2/5 1-3 小时 新手友好度 70/100
-
难度 2/5 1-3 小时 新手友好度 70/100
-
难度 2/5 1-3 小时 新手友好度 70/100
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 70/100
block/artifact-swap#173 ·
-
enhancement low priority
难度 2/5 1-3 小时 新手友好度 85/100
eugenioenko/ttt#674 ·
维护者通常 1 天内回复
-
app CLI enhancement TUI windows-os
难度 2/5 1-3 小时 新手友好度 72/100
维护者通常 1 天内回复
-
cursor
难度 2/5 1-3 小时 新手友好度 78/100
ljofreflor/jobbot#92 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 84/100
use-agent-os/agent-os#3431 ·
维护者通常 2 天内回复