What happens
The same failing check is named two different ways depending on the output format. Both are human-facing text.
$ echo "docs: revamped the profile" | commit-check -m --subject-imperative=true --no-banner
CC003 subject-imperative check failed ==> docs: revamped the profile
↑ kebab
$ echo "docs: revamped the profile" | commit-check -m --subject-imperative=true --compact
[FAIL] CC003 subject_imperative: docs: revamped the profile
↑ snake
Reproduced against 2.13.1.
Why the two forms exist
Both conventions are deliberate, and this is not an argument for collapsing them:
| Surface |
Form |
Matches |
| Default text |
subject-imperative |
the rules reference headings — ### subject-imperative (CC003) |
--format json, check field |
subject_imperative |
the cchk.toml key |
--compact |
subject_imperative |
— |
util.py already says why the default output converts:
# The kebab-case form is what the rules reference uses as its headings, so
# the name printed here can be searched for there verbatim.
name = check_type.replace("_", "-")
JSON keeping the snake_case form looks right and should not change — it mirrors the config key, so a consumer can go from a failure straight to the option that controls it. Changing it would break anything already parsing that field.
--compact is the one that sits on the wrong side: it is text for a human reading a CI log, but it prints the machine form, so the name cannot be pasted into the rules reference the way the default output's can.
Where
_print_failure in commit_check/util.py takes the raw key on the compact path, while the non-compact path reaches print_error_message, which converts:
if compact:
compact_value = actual.splitlines()[0] if actual else actual
label = f"{rule_id} {check['check']}" if rule_id else check["check"]
print(f"[FAIL] {label}: {compact_value}")
return
Applying the same .replace("_", "-") there would line the two text formats up and leave JSON alone.
Impact
Cosmetic, and the reason I noticed it rather than a bug I hit: the commit-check.com pages document both forms correctly today, because each was checked against real output. The inconsistency just means the docs have to show two spellings of one name.
Happy to send a patch if you want it — it is a one-line change plus a test, but it does alter output that someone could be grepping for, so it is your call whether that belongs in a minor or a major.
What happens
The same failing check is named two different ways depending on the output format. Both are human-facing text.
Reproduced against 2.13.1.
Why the two forms exist
Both conventions are deliberate, and this is not an argument for collapsing them:
subject-imperative### subject-imperative (CC003)--format json,checkfieldsubject_imperativecchk.tomlkey--compactsubject_imperativeutil.pyalready says why the default output converts:JSON keeping the snake_case form looks right and should not change — it mirrors the config key, so a consumer can go from a failure straight to the option that controls it. Changing it would break anything already parsing that field.
--compactis the one that sits on the wrong side: it is text for a human reading a CI log, but it prints the machine form, so the name cannot be pasted into the rules reference the way the default output's can.Where
_print_failureincommit_check/util.pytakes the raw key on the compact path, while the non-compact path reachesprint_error_message, which converts:Applying the same
.replace("_", "-")there would line the two text formats up and leave JSON alone.Impact
Cosmetic, and the reason I noticed it rather than a bug I hit: the commit-check.com pages document both forms correctly today, because each was checked against real output. The inconsistency just means the docs have to show two spellings of one name.
Happy to send a patch if you want it — it is a one-line change plus a test, but it does alter output that someone could be grepping for, so it is your call whether that belongs in a minor or a major.