fix: propagate fatal git errors from hasCommits - #331
Conversation
|
Warning Review limit reachedNext included review available in 10 minutes. View limit detailsLimit details: You’ve used the included review currently available. This review ran on the open-source allowance, not this organization's plan, because the pull request author doesn't have an assigned seat. Waiting won't change this — ask an organization admin to assign them a seat, or add seats in Billing if every seat is already assigned, then retry. Review configuration: ⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Advanced Run ID: 📒 Files selected for processing (2)
Comment |
There was a problem hiding this comment.
All reported issues were addressed
Shadow auto-approve: would not auto-approve because issues were found.
Re-trigger cubic
There was a problem hiding this comment.
All reported issues were addressed across 2 files
Shadow auto-approve: would not auto-approve because issues were found.
Re-trigger cubic
|
There was a problem hiding this comment.
0 issues found across 2 files (changes from recent commits).
Confidence score: 5/5
- Automated review surfaced no issues in the provided summaries.
- No files require special attention.
Shadow auto-approve: would require human review. This PR changes hasCommits() to propagate fatal Git errors unless the repo is unborn; a human should review the error propagation implications.
Re-trigger cubic



Fixes #306
hasCommits()now treats only an unborn symbolicHEADwith no stored branch ref as the legitimate zero-commit case. Fatal Git failures (including detached or corruptHEAD/refs) are rethrown with Git stderr preserved.Adds a regression test that corrupts the current branch ref and verifies the Git failure is surfaced instead of being reported as an empty repository.
Validation attempted locally, but the execution environment cannot resolve github.com. CI should run the full format and test matrix.