[Bug] hasCommits() turns fatal Git errors into a false “no commits” result

[404-Page-Found]

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

1. Use a Git repository with a valid working tree but a broken HEAD/object database, or inject a non-zero Git error from the hasCommits() dependency in a unit test.
2. Run commit-echo suggest.
3. 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.

[404-Page-Found]

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.