Repository navigation
[Bug] hasCommits() turns fatal Git errors into a false “no commits” result #306
Description
Description
hasCommits() catches every error from git rev-list --count HEAD and returns false. The caller in suggestCommand() interprets false specifically as “this repository has no commits yet.”
That means an actual Git failure — for example an unreadable/corrupt object database or an invalid HEAD — is reported to the user as an empty repository instead of surfacing the Git error.
Location
src/git/diff.ts:96-108
export function hasCommits(): boolean {
try {
const count = execFileSync(getGitExecutable(), ['rev-list', '--count', 'HEAD'], {
encoding: 'utf-8',
stdio: 'pipe',
}).trim();
return Number.parseInt(count, 10) > 0;
} catch {
return false;
}
}The result is consumed by src/commands/suggest.ts as the explicit “no commits” precondition.
Steps to reproduce
- Use a Git repository with a valid working tree but a broken
HEAD/object database, or inject a non-zero Git error from thehasCommits()dependency in a unit test. - Run
commit-echo suggest. - Observe the “This repository has no commits yet” message.
Expected behavior
An actually empty repository should return false, but unrelated Git failures should propagate as Git errors so the user can repair the repository.
Actual behavior
All rev-list failures collapse to the same boolean value, making empty repositories indistinguishable from broken repositories.
Suggested fix
Distinguish the legitimate empty-history case from command failure — for example by checking/verifying HEAD separately and only returning false when Git confirms that no commit exists. Preserve and surface stderr for other failures.
Impact
Users can be sent down the wrong recovery path, and genuine repository corruption or access failures are masked. This is especially confusing because the current code already has explicit handling for the normal zero-commit repository case.
Reviewed against current main at c67ff967a018d5fd4b032f6ef6a4981ac9d76a12.
Activity
404-Page-Found commentedon Sep 20, 2026
Triage
Priority: P3 — diagnostics / correctness
The defect masks real Git failures as the legitimate zero-commit case. It does not corrupt commits, but it makes repository repair harder and can send users toward the wrong diagnosis.
Disposition: Fix as part of Git error-handling cleanup; lower urgency than the hook and provider hangs/data-integrity issues.
Suggested implementation: distinguish “no HEAD/zero commits” from rev-list execution failures and preserve Git stderr for the latter. Add a test for a repository state that produces a fatal rev-list error.
404-Page-Found commentedon Sep 24, 2026
Triage update
Confirmed against current
main.hasCommits()catches everygit rev-list --count HEADfailure and returnsfalse, whilesuggestCommand()interpretsfalseexclusively as “no commits yet.”HEAD, missing/corrupt objects, and other Git failures can be misreported as an empty repository.false, but propagate other Git failures with stderr. The CLI already has top-level error handling for thrown failures.falseand post-committrue; add a regression test proving a fatalrev-listfailure throws rather than returningfalse.Recommended scope is limited to
src/git/diff.tsplus the regression test, with user-facing formatting handled consistently in the existing command error path.404-Page-Found commentedon Sep 24, 2026
Implemented in PR #331: #331
hasCommits()now returnsfalseonly for an unborn symbolicHEADwith no stored branch ref; fatal Git failures propagate with Git stderr. Added regression coverage for a corrupt branch ref.