Commit subject length incorrectly detected as `> 90` chars

[polarathene]

I experienced this bug here

• Original commit failing: containerd/containerd@364bf95
• Two blank lines to separate subject passes: containerd/containerd@3ca39ef

Failure occurring at:

git-validation/rules/shortsubject/shortsubject.go

Lines 32 to 37 in be39cec

	if len(c["subject"]) >= 90 {
	vr.Pass = false
	vr.Msg = "commit subject exceeds 90 characters"
	return
	}
	vr.Pass = true

git-validation/git/commits.go

Line 102 in be39cec

"%s": "subject",

Presumably related to what's going on here (but I've not troubleshooted further):

git-validation/git/commits.go

Lines 177 to 184 in be39cec

	// CommitEntry represents a single commit's information from `git`.
	// See also FieldNames
	type CommitEntry map[string]string
	// LogCommit assembles the full information on a commit from its commit hash
	func LogCommit(commit string) (*CommitEntry, error) {
	c := CommitEntry{}
	for k, v := range FieldNames {

---

Failing commit message:

fix: Remove `LimitNOFILE` from `containerd.service`

Remove `LimitNOFILE` from `containerd.service` to rely on the systemd v240 implicit default of `1024:524288`. On supported platforms with systemd prior to v240, packagers will patch the service with an explicit `LimitNOFILE=1024:524288`.

- `1024` soft limit is an implicit default, avoiding unexpected breakage. Software that needs a higher limit should request to raise the soft limit for its process.
- `524288` hard limit is an implicit default since systemd v240 and is adequate for most processes (_half of the historical limit from `fs.nr_open` of `1048576`_), while 4096 is the implicit default from the kernel (often too low).
- The hard limit may not exceed `fs.nr_open` (_which a value of `infinity` will resolve to_). On most systems with systemd v240 or newer, this will resolve to an excessive size of 2^30 (over 1 billion).
- When set to `infinity` (usually as the soft limit) software may experience significantly increased resource usage, resulting in a performance regression or runtime failures that are difficult to troubleshoot.

Signed-off-by: Brennan Kinney <5098581+polarathene@users.noreply.github.com>

FAIL - Results in:

 * 364bf956 "fix: Remove `LimitNOFILE` from `containerd.service` Remove `LimitNOFILE` from `containerd.service` to rely on the systemd v240 implicit default of `1024:524288`. On supported platforms with systemd prior to v240, packagers will patch the service with an explicit `LimitNOFILE=1024:524288`." ... FAIL
    - PASS - commit does not have any whitespace errors
    - PASS - has a valid DCO
    - FAIL - commit subject exceeds 90 characters

PASS - While adding another blank line after the subject was successful 🤷‍♂️

   * 3ca39ef0 "fix: Remove `LimitNOFILE` from `containerd.service`" ... PASS
    - PASS - commit does not have any whitespace errors
    - PASS - has a valid DCO
    - PASS - commit subject is 72 characters or less! *yay*

Not sure if it's due to the content/formatting potentially throwing it off? Both locally on my git client and Github's own web view of the commit, presented the correct commit subject with the original commit (21 chars to spare within the 72 limit).

[vbatts]

I'm trying to troubleshoot and really unsure what's happening here. Like, why it pulled-in the next lines as the "subject" line... Like, I wonder if it was some funky CRLF ?

I couldn't fetch containerd/containerd@364bf95 to a local git client. Seems it's only viewable on github.