63 MB of superseded demo video is still in git history

[zangjiucheng]

v1.2.0 moved docs/public/demo.{mp4,webm} into Git LFS, which stops future re-records from adding pack weight. It does not shrink existing clones — the old blobs are still in history.

The measurement

The pack is roughly 127 MB. Video accounts for 7 blobs / 63 MB, and video does not delta-compress, so that is close to half the clone cost for a single asset:

15.2 MB  docs/public/demo.mp4       <- current
15.2 MB  docs/public/demo.webm      <- current
13.7 MB  docs/public/demo-4k.mp4    <- deleted long ago
 6.1 MB  docs/public/demo.mp4       <- superseded
 5.0 MB  docs/public/demo.mp4       <- superseded
 4.2 MB  docs/public/demo.webm      <- superseded
 3.7 MB  docs/public/demo.webm      <- superseded

More than half of it (~33 MB) is files that exist on no branch.

What it takes

git lfs migrate import --everything --include='*.mp4,*.webm'

then force-push every branch.

Why it is not simply done

That rewrites every commit SHA on every branch. It breaks open PRs and every fork, and everyone with a clone must re-clone or hard-reset. main and dev also carry a non_fast_forward rule, so branch rulesets need temporary changes.

This wants an announcement window and a quiet moment with no open PRs — it is a coordinated decision, deliberately not a solo one.

Alternative worth weighing first

The repo already has this pattern: scripts/fetch-pdfium.mjs fetches a binary at postinstall rather than committing it. The demo video could live on a GitHub Release and be fetched during the docs build — no LFS quota exposure, no history rewrite for future assets. It would not reclaim the 63 MB already in history.

---

_{Found during v1.3.0 research: parallel codebase surveys, then each finding independently verified against the code before filing. Line numbers are from dev at the time of writing.}