Skip to content

Fix enableGitInfo being silently discarded by TOML scoping - #128

Merged
vpetersson merged 1 commit into
sbomify:masterfrom
vpetersson-bot:fix-enablegitinfo-toml-scope
Aug 4, 2026
Merged

Fix enableGitInfo being silently discarded by TOML scoping#128
vpetersson merged 1 commit into
sbomify:masterfrom
vpetersson-bot:fix-enablegitinfo-toml-scope

Conversation

@vpetersson-bot

Copy link
Copy Markdown
Contributor

You asked whether the missing dates were a shallow clone. They weren't — it's a TOML scoping bug, and the setting has never done anything.

The bug

[pagination]
  pagerSize = 12
  path = "page"

enableGitInfo = true          # <-- parsed as pagination.enableGitInfo
ignoreFiles   = [...]         # <-- parsed as pagination.ignoreFiles

TOML assigns every bare key to the table that precedes it. Both keys were being folded into [pagination] and dropped — hugo config has no root-level enablegitinfo among its 666 lines, and the resolved [pagination] contains only pagersize and path.

Ruled out the alternatives before concluding: the deploy workflow already uses fetch-depth: 0, the local clone has full history (508 commits), and security.exec.allow already permits ^git$. Building with the --enableGitInfo flag populates .GitInfo immediately from the same working tree — so only the config key was at fault.

What it was costing

Three follow-on corrections

Enabling it naively would have introduced new inaccuracies, so:

  1. The guides TechArticle no longer takes datePublished from .Lastmod. .Lastmod is the file's latest commit — with GitInfo live it would restamp a guide as newly published on every edit. datePublished now comes only from an explicit frontmatter date; .Lastmod supplies dateModified alone.
  2. The FAQ WebPage dateModified is guarded on .Lastmod.IsZero — that is the exact field that shipped the 28 zero dates, so it can't do so again if the config regresses.
  3. Blog post meta and BlogPosting schema restricted to .Kind "page". /blog/ and its 7 paginated pages share Type "posts" but have no date, so they were emitting BlogPosting and article:published_time with zero dates while already carrying their own CollectionPage.

On (3): the listing's breadcrumb came from that same gated block, so restricting it removed breadcrumbs from /blog/. I caught that in the entity diff and re-emit the breadcrumb alongside the CollectionPage instead.

Verification

Production build, entity counts before vs after:

type before after
BlogPosting 99 91
BreadcrumbList 172 172
TechArticle 64 64
FAQPage 62 62
VideoObject 33 33
(all others) unchanged

The single delta is the intended one. Also:

  • zero dates site-wide: 28 → 0
  • sitemap <lastmod>: 0 → 314
  • invalid JSON-LD: 0, entities missing a required property: 0

bun run lint and the production build both pass.

🤖 Generated with Claude Code

https://claude.ai/code/session_01FbqYj6ztzG6yautDpRWDXS

enableGitInfo = true sat directly beneath the [pagination] table
header. TOML assigns every bare key to the table that precedes it, so
it was parsed as pagination.enableGitInfo and dropped -- `hugo config`
had no root-level enablegitinfo among its 666 lines. ignoreFiles, two
lines further down, was lost the same way.

The setting has therefore never done anything. Not a shallow clone:
the deploy workflow already uses fetch-depth: 0, the local clone has
full history, and security.exec.allow already permits git. Confirmed by
building with the --enableGitInfo flag, which populates .GitInfo
immediately from the same working tree.

The visible damage was 28 FAQ pages shipping
"dateModified":"0001-01-01T00:00:00Z" in live structured data, and a
sitemap with no <lastmod> at all. Moving both keys above the first
table header gives 314 sitemap lastmod entries and real dates
throughout.

Three follow-on corrections, without which enabling it would have
introduced new inaccuracies:

  - The guides TechArticle no longer takes datePublished from .Lastmod.
    .Lastmod is the file's latest commit, so with GitInfo live it would
    have restamped a guide as newly published on every edit.
    datePublished is now emitted only from an explicit frontmatter date;
    .Lastmod supplies dateModified alone.
  - The FAQ WebPage dateModified is guarded on .Lastmod.IsZero. That is
    the exact field that shipped the 28 zero dates, so it should not be
    able to do so again if the config regresses.
  - The blog post meta and BlogPosting schema are restricted to
    .Kind "page". The /blog/ listing and its 7 paginated pages share
    Type "posts" but have no date, so they were emitting BlogPosting and
    article:published_time with zero dates while already carrying their
    own CollectionPage. Their breadcrumb came from that same block, so
    it is re-emitted alongside the CollectionPage rather than lost.

Verified against a production build. The only entity-count change is
BlogPosting 99 -> 91, the eight listing pages; BreadcrumbList holds at
172 and every other type is unchanged. Zero dates across the site go
28 -> 0, invalid JSON-LD stays 0, and no entity is missing a required
property.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FbqYj6ztzG6yautDpRWDXS
@vpetersson
vpetersson merged commit 847c674 into sbomify:master Aug 4, 2026
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants