Skip to content

committedAt in the --json schema is serialised by git, so its format changes with the user's git version #650

Description

@MongLong0214

commitlore query --json exposes committedAt as a public schema field, but its value is a raw slice of git's %cI output. Git changed how it renders a UTC offset, so the same commit produces two different strings depending on which git the user has.

Reproduced

One commit object, one fixed date, two gits:

$ GIT_AUTHOR_DATE="2026-02-01T00:00:00Z" GIT_COMMITTER_DATE="2026-02-01T00:00:00Z" \
    git commit --allow-empty -m x

git 2.50.1 => 2026-02-01T00:00:00Z
git 2.39.5 => 2026-02-01T00:00:00+00:00

src/commands/stale.ts:51 reads const LOG_FORMAT = %H${UNIT}%cI${UNIT}%B`` and line 102 slices the field straight out; src/commands/query.ts:298 passes it into the JSON payload unchanged. The same `%cI` also feeds `committed_at` in the index (`src/core/index-db.ts:686`, `:834`).

Why it is a defect rather than a cosmetic difference

  • committedAt is part of a documented output contract. A consumer that compares strings, matches a pattern, or feeds a strict parser gets different results on different machines for the same repository.
  • git >= 2.9 is the version this product declares it supports (src/commands/doctor/checks/runtime-git-trailers.ts:25). git 2.39.5 is Debian bookworm's git — current Debian stable, not an exotic configuration.
  • The test that should have caught it is named --json > emits the stable schema. It pins one of the two renderings, so it passes only because the runners happen to ship a newer git.

Ordering is not affected: %ct is stored separately and is what sorts (src/core/index-db.ts:38). The damage is confined to the string a consumer reads.

How it was found, and the gap it points at

Running the full suite inside node:22.23.2-bookworm while diagnosing something unrelated. CI never sees it because git-matrix runs only ubuntu-latest and macos-latest, both of which carry a recent git — so the matrix that exists to vary git does not actually vary it across the range the product claims to support.

That is arguably the larger finding: a green matrix is being read as evidence about old git while testing only new git.

Suggested acceptance

  • committedAt renders identically on every supported git, normalised by this product rather than inherited from git's formatting
  • a regression that fails when the two renderings diverge, exercised against a git old enough to produce the offset form
  • git-matrix covers a git near the declared floor, or the declared floor moves to a version whose output this product has actually tested

Metadata

Metadata

Assignees

No one assigned

    Labels

    release:0.9.0Must close before 0.9.0: an unaware user gets a wrong result, or the docs already promise it

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions