site: take sitemap dates from git, because mtime is a lie in CI - #7
Merged
Conversation
The lastmod fix in #5 worked locally and did nothing in production. Deployed, all eighteen URLs still carried one identical date -- 2026-08-30T04:07:33, the build's own checkout time. mtime was the wrong source. A git clone stamps every file it writes with the moment it wrote it, so on a CI checkout every file in the tree shares one mtime and the per-page dates collapse straight back into the single build timestamp the change existed to remove. A working tree has real edit times, which is exactly why local verification passed and proved nothing. Reproduced by cloning the repository and comparing the two sources against the same thirteen files: distinct mtimes: 1 distinct git dates: 6 Six rather than thirteen because several docs were committed together, which is the honest answer: those pages did change at the same moment. So the date now comes from `git log -1 --format=%cI -- <path>`, which is a record of when the content changed rather than when the machine last touched the file. mtime stays as a fallback for a build with no git history, where it is no worse than the build clock it replaces, and the build clock remains the last resort. Verified against a build rather than a working tree: nine distinct dates across the eighteen URLs. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Y5jnkZKX4AdPgBMzMosxE7
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The lastmod fix in #5 worked locally and did nothing in production. Deployed, all eighteen URLs still carried one identical date —
2026-08-30T04:07:33, the build's own checkout time.Why
mtime was the wrong source. A git clone stamps every file it writes with the moment it wrote it, so on a CI checkout every file shares one mtime and the per-page dates collapse straight back into the single build timestamp the change existed to remove.
A working tree has real edit times. That is exactly why local verification passed and proved nothing — the one environment where mtime works is the one environment that never serves the sitemap.
Reproduced
Cloned the repo and compared both sources against the same thirteen files:
Six rather than thirteen because several docs were committed together — the honest answer, since those pages did change at the same moment.
The fix
The date now comes from
git log -1 --format=%cI -- <path>: a record of when the content changed, not when the machine last touched the file. mtime stays as a fallback for a build with no git history, where it is no worse than the build clock it replaces, and the build clock remains the last resort.Verified against a build, not a working tree
Nine distinct dates across the eighteen URLs in
.next/server/app/sitemap.xml.body.Full suite 243 passing, typecheck clean.
🤖 Generated with Claude Code
https://claude.ai/code/session_01Y5jnkZKX4AdPgBMzMosxE7