You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Worktrees() reports a worktree on an unborn branch as sitting at commit 0000000… instead of Head = null #165
In a repository with no commits yet, git worktree list --porcelain still prints a HEAD line, and its value is the null object id. Reproduced with git 2.43 on a freshly git init-ed repository:
worktree /tmp/ub
HEAD 0000000000000000000000000000000000000000
branch refs/heads/master
GitWorktreeParser passes that value straight into GitCommitSha, whose regex ^[0-9a-fA-F]{4,64}$ accepts forty zeros:
So GitWorktree.Head comes back looking like a real commit id. That contradicts two documented intents:
GitWorktree.Head's documentation says null means "git reported none".
The worktrees design makes Head nullable so the library never invents a value.
The all-zero id is git's sentinel for "no commit". It is not a commit.
Failure scenarios
A launcher lists worktrees right after Init() and passes worktree.Head to Log().ForRevision(...) or RevParse(...). Git fails with bad revision '0000000…', and nothing in the returned model warned the caller.
Two worktrees on different unborn branches report equal Head values, so a caller comparing heads wrongly concludes they are at the same commit.
A caller checking Head is null to detect "nothing to show" never sees null in this case.
Precedent in this repository
GitSubmoduleParser already treats the all-zero id as "none", through IsNullObjectId (GitIntegration/Parsing/GitSubmoduleParser.cs around L300, added for #103). It checks every character is a zero, so the 64-character SHA-256 form is covered too. The worktree parser does not reuse it.
Suggested fix
Move IsNullObjectId into GitParseValues or another shared internal helper.
Use it in GitWorktreeParser, so an all-zero HEAD yields Head = null.
Update the GitWorktree.Head remarks to say an unborn branch also reports null.
Acceptance criteria
Parser tests for an all-zero HEAD in both the 40-character and 64-character forms.
An integration test that calls Worktrees() on a freshly initialised repository and gets Head == null.
This is separate from #141, which covers newline paths and C-quoted lock/prunable reasons in the same parser.
Priority: Low. It only affects a repository or worktree on an unborn branch, which in practice means one with no commits yet. The contract violation is real (Head should be null), but callers rarely reach it, and the fix reuses existing code.
Area / suggested assignment: Parsing, in GitWorktreeParser together with GitSubmoduleParser.IsNullObjectId. Whoever owns the worktrees feature should take it.
Next step: Move IsNullObjectId into a shared helper such as GitParseValues and apply it to worktree HEAD. Add parser tests for the 40- and 64-character forms, plus a Worktrees() integration test on a freshly initialised repository.
Activity
matt-edmondson commentedon Sep 29, 2026
Triage
Headshould be null), but callers rarely reach it, and the fix reuses existing code.GitWorktreeParsertogether withGitSubmoduleParser.IsNullObjectId. Whoever owns the worktrees feature should take it.IsNullObjectIdinto a shared helper such asGitParseValuesand apply it to worktreeHEAD. Add parser tests for the 40- and 64-character forms, plus aWorktrees()integration test on a freshly initialised repository.Generated by Claude Code