Hacktoberfest 2026:维护者为十月标记出来的 issue,仍然开放、适合新手。 浏览 Hacktoberfest issue

**My work entry becomes permanently unusable and un-removable when a PR's bas...

未关闭
#4,143 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

还没有人认领这个 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

  1. Have a PR whose base branch exists (works normally at this point).

  2. Merge it (squash), then delete the head and base branches.

  3. Open My work — the PR is still listed (seen in the All and Done views).

  4. 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>/head still resolves after a merge, but a single git fetch with 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, and git for-each-ref shows 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-ref does 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

环境准备

从这里开始

  1. 先读完整个 Issue,再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库,在一个分支上完成修改。
  4. 提交 Pull Request,并在描述里引用这个 Issue 编号。

github/app 的其他 Issue

查看 github/app 的全部 Issue

相似的 Issue

更多 CLI Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。