mirror of
https://github.com/harvard-edge/cs249r_book.git
synced 2026-05-07 18:18:42 -05:00
c1611bd5c4
The "going-forward" LFS rules in .gitattributes were creating
phantom-modification noise on every PDF and MP3 that was committed
before the rules existed. The LFS clean filter would compute a
133-byte pointer in memory that never matched the raw blob in HEAD,
so 26 PDFs and 2 MP3s permanently showed as `M` in `git status`.
Pre-commit's stash mechanism then crashed on those phantom-dirty
binaries (today's 00_tinytorch.pdf hook failure being the latest
symptom).
The set of files actually backed by LFS was small: 11 paper figures
totalling ~540 KB, all derivable from SVG sources committed alongside
them. The bandwidth/storage benefit of LFS for that scope is
negligible, and the operational cost (LFS hooks, smudge/clean filter
surprises, collaborator setup) is real.
Changes:
- Drop all 9 *.{pdf,epub,mp3,wav,m4a,mp4,mov,webm,wasm} LFS rules
from .gitattributes; keep the text-handling normalization.
- Re-stage the 11 LFS-tracked paper figures via `git add --renormalize`,
converting them from 133-byte pointers to raw blobs in HEAD.
Past commits in history retain LFS pointers for those 11 figures.
Anyone needing to check out a pre-this-commit revision and rehydrate
the binaries still needs git-lfs installed; new clones at this tip
or later don't.
Future direction: the paper figures are build artifacts derivable from
their SVG sources. A follow-up should add them to .gitignore and have
the paper-build workflow regenerate them on demand.