fix(git): surface git log failures instead of swallowing them as empty range - #448
Merged
Merged
Conversation
…y range GetCommits returned (nil, nil) whenever git exited non-zero with empty stdout, treating a bad or unknown base SHA, a shallow clone missing the base commit, or a non-repository as an empty commit range. Callers then saw zero commits, computed no version bump, and cut the same version with no warning. A legitimately empty range exits 0 and already returns no commits via parseCommits, so any error from git log is a real failure and is now returned. Signed-off-by: Joshua Temple <joshua.temple@stablekernel.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
git.GetCommitstreated any git failure that produced empty stdout as an empty commit range and returned(nil, nil), swallowing the error. A genuinely empty range already exits 0, so that branch was reached only when git exited non-zero: a bad or unknown base SHA after a history rewrite, a shallow clone missing the base commit, or a non-repository path. The caller then saw zero commits, derived no version bump, and recomputed the same base version. The result was a silent wrong-version cut with no warning logged.Fix
Distinguish exit status from empty output. Return the wrapped error when git exits non-zero, and keep the empty-range case (exit 0, no output) returning no commits and no error.
Verification
go build ./...,go test ./... -race -count=1, andgolangci-lint run ./...all clean locally, including a new test that asserts a non-zero git exit surfaces an error rather than an empty slice.