Restore mtimes in the local release too, so both paths fail the same way

[ptr727]

Follow-on to #75, at the maintainer's request: the local release path should mimic what CI does.

The gap, and why it was invisible

deploy/make-release.sh restored nothing and asserted nothing. That went unnoticed because this host's working tree is long-lived, so static/ already carries old mtimes and local releases were linking 1052 files while CI linked zero.

A fresh clone here — a clean-room build, a second checkout, a new machine — would have reproduced the CI defect exactly, silently, and cost a full copy per release.

What changed

git-restore-mtime is now required, not optional. Absent, the release refuses and names the version to install. Skipping when a tool is missing is precisely how the CI version shipped broken for four releases.

The assertion is the same self-calibrating one the workflow uses — nothing under static/ may be newer than HEAD's commit — with one difference CI does not need: locally modified and untracked paths are excluded. A working tree can legitimately hold a static file newer than any commit, and skipping the check whenever the tree is dirty would make it useless during an edit loop. A clean tree takes the same single find the workflow runs.

Demonstrated failing before being trusted

1. not installed
   git-restore-mtime not found on PATH
     it is what makes --link-dest able to link, and a release built without it is a full copy
     install git-tools v2025.08 or newer -- the v2022.12 in Debian and Ubuntu calls
     'git whatchanged', which current git refuses to run, so it restores nothing and exits 0
   exit=1

2. installed but silently doing nothing   <- the real v2022.12 bug, reproduced with a stub
   ==> restoring file mtimes
     1,052 files to be processed in work dir
   mtime restore did nothing: static/ holds unmodified files newer than HEAD's commit,
     so they still carry their checkout time and --link-dest will link nothing
   exit=1

3. working v2025.08
   1,052 files updated
   ==> mtimes restored, newest 1785594994 against HEAD 1786280126

Case 2 is the one that matters: the stub prints the same reassuring line the broken tool prints, and the gate catches it anyway.

The finding worth reading, which is not a defect

The first restored release cannot link, by construction. It is compared against a predecessor built with unrestored mtimes, so nothing matches and the existing zero-shared-files guard fires and refuses the release.

That guard is correct. The changeover needs one NO_LINK_DEST=1 release to seed a restored generation — which is exactly what that knob exists for. Measured on the staging mirror:

Release	Result
first restored, against an unrestored predecessor	0 of 3269 — guard refuses
seeded with NO_LINK_DEST=1	full copy, installs
the next ordinary release	1052 of 3269 files hard-linked

1052 is the same number the two-clone measurement in #65 predicted, and the same count Hugo reports as static files. The mirror answers PASS - 1253 URLs honored afterwards.

This applies to the VPS too, and it corrects what I told the host side in §R. Their next deploy will link 0, not ~1052, because it compares against 20260809-030521 which was built with unrestored mtimes. The deploy has no equivalent guard so it will simply proceed; the deploy after that is the one where the shared-inode count should jump. I am telling them so they do not read the expected zero as the fix having failed again.

[Copilot]

Pull request overview

This PR updates the local release script to restore static/ file mtimes and enforce the same “restore actually happened” assertion used in CI, so local releases fail loudly (instead of silently producing full-copy releases) when mtime restoration is missing or ineffective.

Changes:

• Require an mtime-restore tool before building a release, instead of allowing a silent fallback.
• Restore mtimes for static/ and assert no clean static/ file is newer than HEAD’s commit time (with local exclusions for modified/untracked paths).

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.

Suppressed comments (2)

deploy/make-release.sh:121

• With set -euo pipefail, this command substitution will exit the script immediately if the grep finds no match (exit=1), so the intended if [ -z "$mtime_version" ] error message never runs. This can turn a version-format change (or unexpected output) into a silent hard exit without the helpful diagnosis.

mtime_version="$("${MTIME_CMD[@]}" --version 2>/dev/null | grep -oE '[0-9]{4}\.[0-9]{2}' | head -1)"

deploy/make-release.sh:153

• The git status --porcelain -z output is not always one NUL-separated record per path (e.g., renames/copies include two paths), so stripping a fixed 3-byte prefix (${entry:3}) can mis-populate mtime_dirty. That can make the exclusion set incomplete and cause the mtime assertion to fail even though the only “newer than HEAD” files are part of a rename/copy that should have been excluded as uncommitted.

declare -A mtime_dirty=()
while IFS= read -r -d '' entry; do
	mtime_dirty["${entry:3}"]=1
done < <(git status --porcelain -z -- static)

[ptr727]

Both fixed in 69b1cad. Both were in code I added one commit earlier, and both made a guard describe a case it could not reach.

1. The version diagnostic was unreachable

With set -euo pipefail, this command substitution will exit the script immediately if the grep finds no match.

Reproduced in isolation before touching anything:

before
exit=1          <- "after:" never printed, the diagnostic never ran

So an unparseable version would have surfaced as a bare exit 1 with no message — the same silent shape this whole change exists to eliminate, in the guard meant to eliminate it. The assignment now tolerates the failed match, verified with a stub reporting version unknown:

git-restore-mtime did not report a version, so it cannot be checked for the whatchanged defect
exit=1

2. A rename emits two records

The git status --porcelain -z output is not always one NUL-separated record per path.

Correct. Confirmed against a real rename in static/:

R  static/apple-touch-icon-renamed.png
static/apple-touch-icon.png

The loop read the second as another status record and stripped three characters off a bare path — recording tic/a.txt for static/a.txt. The real path then stayed out of the exclusion set, so the assertion could fail on a file that is legitimately uncommitted. Exactly the failure you described.

Both halves are now excluded, since both are uncommitted:

excluded: static/apple-touch-icon-renamed.png
excluded: static/apple-touch-icon.png
==> 2 uncommitted path(s) under static/, excluded from the mtime check
1051 of 3269 files hard-linked

1051 rather than 1052 — the renamed file correctly not matching the previous release. The rename was reverted afterwards and the mirror rebuilt from the clean tree, answering PASS - 1253 URLs honored.

Tested with an actual git mv rather than a hand-written porcelain string, because the thing in doubt was what git emits.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.

Suppressed comments (1)

deploy/make-release.sh:134

• If both invocation forms are present, the script always prefers git-restore-mtime on PATH. That means a stale PATH install (e.g., v2022.12) will cause an early failure even when git restore-mtime is also available and meets MTIME_MIN. To better match the intent of “accept both forms”, consider falling back to the other form when the initially selected command is below MTIME_MIN.

if [ "${mtime_version//./}" -lt "${MTIME_MIN//./}" ]; then
	echo "${MTIME_CMD[*]} is $mtime_version, and $MTIME_MIN or newer is required" >&2
	echo "  before $MTIME_MIN it calls 'git whatchanged', which current git refuses to run, so it" >&2
	echo "  restores nothing and still exits 0 -- every release would silently be a full copy" >&2
	exit 1
fi

[ptr727]

Fixed in f5330b4. Correct, and the phrasing of the finding is the useful part: accepting both forms and then letting the worse one decide is not really accepting both.

A stale manual install at /usr/local/bin would veto a current packaged one behind it, and the release would refuse to build with a perfectly good tool present.

Each candidate is now version-checked and the first acceptable one wins, rather than the first that merely exists. It refuses only when none meets the floor, and names what it found instead of only what it wanted.

Measured with a 2022.12 stub on PATH and a real 2025.08 in git's exec-path:

==> restoring file mtimes with git restore-mtime 2025.08
==> 1052 of 3269 files hard-linked

And with only the stale one reachable:

no usable git-restore-mtime: found git-restore-mtime 2022.12, git restore-mtime 2022.12,
and 2025.08 or newer is required

One detail worth recording from that second run: both forms report the same tool, correctly. git resolves a subcommand from PATH as well as from its exec-path, so a single stale binary genuinely is both candidates. The message says so rather than implying two separate installs.

Mirror still answers PASS - 1253 URLs honored.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.