Skip to content

doctor and hooks status report a stale hook pin as ok: commit-msg still bound to v0.5.0 after upgrading to 0.6.0 #382

Description

@MongLong0214

Summary

After upgrading the CLI (0.5.0 → 0.5.1 → 0.6.0), the repo's git config still pins the commit-msg hook to the v0.5.0 binary. Every commit is therefore validated by 0.5.0 logic while commitlore --version reports 0.6.0. Both doctor and hooks status report this state as healthy — neither compares the pinned binary's version with the running CLI, so the skew is invisible unless you read the path and notice the version number in it.

Observed

$ commitlore --version
0.6.0

$ git config --get-regexp '^commitlore\.'
commitlore.bin   /Users/.../commitlore/v0.5.0/dist/commitlore.mjs
commitlore.node  /Users/.../node/v24.18.0/bin/node
commitlore.root  /Users/.../commitlore/v0.5.0

$ node /Users/.../commitlore/v0.5.0/dist/commitlore.mjs --version
0.5.0

$ commitlore doctor
ok      cli runtime — .../v0.6.0/dist/commitlore.mjs runs (0.6.0)
ok      commit-msg hook — installed at .../.git/hooks/commit-msg; commitlore.bin: .../v0.5.0/dist/commitlore.mjs; ...

$ commitlore hooks status
commit-msg: installed (commitlore)
commitlore.bin: .../v0.5.0/dist/commitlore.mjs

doctor prints the stale path in its own ok line, so it has the value in hand and does not act on it.

All three versions are present on disk, installed hours apart:

Aug  1 04:35  v0.5.0
Aug  1 11:13  v0.5.1
Aug  1 16:41  v0.6.0

The commitlore shell wrapper was rewritten to point at v0.6.0 by the upgrade; the git config pins were not.

Why it matters

The hook is the enforcement point. A repo can be two releases behind on the path that actually validates commits while every diagnostic says it is fine. Any fix shipped in 0.5.1 or 0.6.0 that touches validate, prepare-commit-msg or post-commit silently does not apply.

It also makes the pin a latent breakage: hooks uninstall on an old version directory, or any cleanup of ~/.local/share/commitlore/v0.5.0, turns every commit in that repo into a hook failure.

Expected

Either of:

  1. Upgrading re-points commitlore.bin / commitlore.root in every repo that has the hook installed; or
  2. doctor and hooks status compare the pinned binary's version against the running CLI and report a warning, not ok, when they differ — with the remedy (commitlore hooks install) named.

(2) alone would be enough to make this self-correcting; the upgrade cannot reliably find every repo, but the diagnostic that already prints the path can certainly compare it.

Environment

  • commitlore 0.6.0, macOS 15 (Darwin 25.3.0), git 2.50.1 (Apple Git-155), node v24.18.0
  • installed via install.sh into ~/.local/share/commitlore/

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions