Raised by the fleet audit of this repository at main (16f196e), run stamp audit run 2026-08-15T15:13:26Z | hub d54862a.
What
.gitattributes:29 pins *.Dockerfile to LF, and no tracked file matches that glob. The tree carries a single Docker/Dockerfile, which the Dockerfile text eol=lf pin on the line above already covers.
The hub's scripts/repo_gate.py --check eol-coverage fails on it:
[FAIL] eol-coverage 1 issue(s)
.gitattributes pins `*.Dockerfile` to LF and no tracked file matches it
note: read 5 LF pin(s), 1 of them forward-declared, over 7 shebang file(s) in 186 tracked file(s).
The glob is a leftover from the per-distribution Dockerfiles (Ubuntu.Devel.Dockerfile, Alpine.Edge.Dockerfile, Debian.Testing.Dockerfile) that the consolidation onto one image removed.
Why it matters
A pin that matches nothing is indistinguishable from a pin whose files went missing, which is the case the check exists to catch: a shell script or a Dockerfile that quietly stopped being LF-enforced still reads as pinned. Every dead pin makes the next real one harder to see.
Remedy
Either is correct, and the second is right only if a *.Dockerfile file is genuinely expected back:
- Delete the
*.Dockerfile line. Dockerfile text eol=lf covers what the tree holds.
- Mark the pin's comment block forward-declared, the way the
uv.lock block above it already is, which is the documented way to state "no file matches this yet, on purpose".
Raised by the fleet audit of this repository at
main(16f196e), run stampaudit run 2026-08-15T15:13:26Z | hub d54862a.What
.gitattributes:29pins*.Dockerfileto LF, and no tracked file matches that glob. The tree carries a singleDocker/Dockerfile, which theDockerfile text eol=lfpin on the line above already covers.The hub's
scripts/repo_gate.py --check eol-coveragefails on it:The glob is a leftover from the per-distribution Dockerfiles (
Ubuntu.Devel.Dockerfile,Alpine.Edge.Dockerfile,Debian.Testing.Dockerfile) that the consolidation onto one image removed.Why it matters
A pin that matches nothing is indistinguishable from a pin whose files went missing, which is the case the check exists to catch: a shell script or a Dockerfile that quietly stopped being LF-enforced still reads as pinned. Every dead pin makes the next real one harder to see.
Remedy
Either is correct, and the second is right only if a
*.Dockerfilefile is genuinely expected back:*.Dockerfileline.Dockerfile text eol=lfcovers what the tree holds.uv.lockblock above it already is, which is the documented way to state "no file matches this yet, on purpose".