microsoft / microsoft/vscode

Git extension logs expected ENOENT for common refs in linked worktrees

Open
#327,061 0 comments 0 reactions 1 assignee Claimed by @lszomoru View on GitHub
Dominant language
TypeScript
Stars
193k
Forks
42.4k
PR merge metrics
PR metrics pending

Description

### Type of issue
Bug

### VS Code version
1.129.1 (commit 8a7abeba6e03ea3af87bfbce9a1b7e48fed567b8)

### Reproduction
1. Open a repository linked worktree in VS Code.
2. Let the Git extension resolve a remote-tracking ref such as refs/remotes/origin/dev.
3. Inspect the Git output/log.

### Actual behavior
Git.revParse first reads path.join(this.dotGit.path, ref). For a linked worktree, this points below the private per-worktree gitdir. Normal refs live below GIT_COMMON_DIR, so the speculative read raises ENOENT and logs:

[Git][revParse] Unable to read file: ENOENT ... refs/remotes/origin/dev

The subsequent git rev-parse fallback succeeds. This makes a valid repository look unhealthy and repeats for every affected ref.

### Expected behavior
Expected ENOENT from the speculative direct read should be silent. Other filesystem errors should still be logged, and the existing git rev-parse fallback should remain unchanged.

### Source
extensions/git/src/git.ts, Git.revParse: the catch currently logs every readFile error before falling back to git rev-parse.

### Proposed narrow fix
In that catch, skip the warning only when err.code === ENOENT. Keep the warning for all other errors and keep the existing fallback.

Git documents that refs are shared through the common directory for linked worktrees:
- https://git-scm.com/docs/git-worktree
- https://git-scm.com/docs/gitrepository-layout.html#Documentation/gitrepository-layout.txt-codeGITCOMMONDIRcode

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.