[closer-claudio]

Why

Two decisions on the command's contract, recorded as #34 and #35.

The short-subject rule counted bytes against its limits of 90 and 72, so a subject of 85 accented characters failed as 170 bytes, where GitHub's ellipsis and a reader count characters.

A --range git could not resolve was silently replaced by the whole history the clone has, from its oldest commit. The fallback exists for a shallow CI clone whose depth does not reach the range's start, and it swallowed a typo and a missing ref with it, validating everything and passing.

What

• rules/shortsubject/shortsubject.go: the rule counts runes.
• git/commits.go: the fallback applies to a shallow clone only (git rev-parse --is-shallow-repository); in a repository with its whole history an unresolvable range is an error that names it and the git rev-list command that failed, unwrapping to git's exit as before, with git's own message, and nothing is validated.
• cmd/git-validation/contract_decided_test.go: the contract cases for both: an 89-character non-ASCII subject passes and a 90-character one fails; an unresolvable range exits non-zero with the range on stderr and no commit validated; a shallow clone with a range past its depth still runs over what it has.
• git/contract_test.go, git/commits_test.go: the two pins of the old behaviour move with the decision: the range table's bad range is refused with git's message, and the outside-a-repository error names git rev-list, the command that fails first there.

If the shallow case is to be refused as well, it is the one shallowRepository condition to drop and the third contract case to invert.

Verification

just lint 18/18 and just test (54 tests, plain and under the race detector) on the branch.

Closes #34 and #35.

Created by @apostasie personal assistant

[closer-claudio]

Reviewed at 612f998