perf: build git last-modified map in one pass

[SunsetDrifter]

Why

gen:last-updated and gen:sitemap each spawn git log once per MDX file (~314 spawns each, ~628 total) to read last-modified dates. That's ~15s on every build — local, PR CI, and dev.

First of a short series addressing slow docs builds/deploys.

What

• scripts/git-dates.mjs — add buildGitDateMap(): a single git log --name-only pass building a path → date map, memoised per process. git log is reverse-chronological, so first-seen date per path == what git log -1 -- <path> returned.
• generate-last-updated.mjs / generate-sitemap.mjs — look dates up from the map instead of spawning per file.

Impact

	before	after
gen:last-updated	7.8s	0.94s
gen:sitemap	7.7s	0.54s

Safety

• Output is byte-identical to the previous per-file version (verified by diffing regenerated last-updated-routes.mjs and sitemap.xml against a baseline — no diff).
• Same graceful fallback: when git is unavailable (e.g. inside the Docker image, which has no git binary), the map is empty and pages get no date — exactly as before. No crash, exit 0.
• No change to the deployed artifact — the prod image has no git either way, so prod output is unchanged. This only speeds up local + PR builds.

Test plan

• Both gen scripts produce byte-identical output vs baseline
• git-unavailable path returns empty map, no crash (shimmed git to fail)
• pr-build CI green (full npm run build)

[coderabbitai]

Warning

Review limit reached

@SunsetDrifter, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 14 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 3d6af7a3-a9a5-4043-b906-103a69bf2ac3

📥 Commits

Reviewing files that changed from the base of the PR and between 25898dc and 8605c1c.

📒 Files selected for processing (3)

• scripts/generate-last-updated.mjs
• scripts/generate-sitemap.mjs
• scripts/git-dates.mjs

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch docs/dedupe-git-dates

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}