Migrate 4 videos to Git LFS and document LFS setup#378
Conversation
connections.mp4, data-explorer.mp4, positron-assistant-copytoeditor.mp4, and positron-hero-fast-tour.mp4 were committed as raw binary instead of through the LFS filter, causing phantom diffs for anyone with LFS installed. Re-add them through the filter and add notes to README.md and CLAUDE.md so folks know how to spot and fix this.
✅ Deploy Preview for positron-posit-co ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
Tested fresh clone by running |
juliasilge
left a comment
juliasilge
left a comment
There was a problem hiding this comment.
Thank you for fixing this! I never saw this problem myself 😱 but I have heard of other people running into it. I dug into why I never saw the phantom diff on my own clone even though I do have Git LFS installed.
The 4 videos really were committed as raw binary, not LFS pointers. On main, git cat-file -p main:videos/connections.mp4 returns the raw MP4 bytes (ftypisom...), and git lfs ls-files lists the other 15 videos but not these 4. So when the LFS clean filter runs, it produces a small pointer that doesn't match the large raw blob stored in the commit, which is the phantom diff (Bin 564026 -> 131 bytes).
Whether you actually see that diff comes down to the Git index, not whether LFS is installed:
- Git records
size: 0in the index for any path that goes through a filter, which forces it to re-run the clean filter on everygit status. A fresh clone today (with.gitattributespresent) builds the index that way, runs the filter, and surfaces the phantom diff. - An older local clone has these entries from before they were properly flagged for LFS, so the index stored the real size (564026) and Git takes the stat-cache shortcut: it never re-runs the filter and reports the file as clean.
I verified this by forcing Git to rebuild those index entries (simulating a fresh clone), at which point the phantom diff appeared on my machine too. So "I have LFS installed" isn't the deciding factor; a stale-but-lucky index in an existing clone is why some of us never noticed it while a fresh clone hits it immediately.
|
|
||
| This repository uses [Git LFS](https://git-lfs.com/) to store large files such as videos. Make sure you have Git LFS installed before cloning. | ||
|
|
||
| If you see phantom diffs on video files you didn't change, it usually means those files were committed outside of LFS. Run `git add <file>` to re-add them through the LFS filter, then commit the result. |
There was a problem hiding this comment.
The current wording tells contributors to git add and commit the file, but on a fresh clone that actually rewrites the stored blob into an LFS pointer, which is a real change to history rather than local cleanup. A contributor who just wants a clean tree could end up slipping an LFS migration into an unrelated PR without realizing it. Once this PR merges these 4 files are proper pointers, so the phantom diff shouldn't recur for them anyway; the note is most useful as forward-looking prevention.
| If you see phantom diffs on video files you didn't change, it usually means those files were committed outside of LFS. Run `git add <file>` to re-add them through the LFS filter, then commit the result. | |
| Because videos are stored in Git LFS, install and initialize Git LFS (`git lfs install`) before adding or replacing a video so it goes through the LFS filter. If you ever see a "phantom diff" on a video file you didn't touch, it means that file was committed as raw binary instead of an LFS pointer. Don't commit the change into an unrelated PR: run `git restore <file>` to clear it locally, and flag the file so it can be re-added through LFS on its own. |
This keeps the useful breadcrumb, points contributors at "discard and report" instead of "add and commit," and frames it as prevention rather than an expected ongoing state.
| ## Videos and Git LFS | ||
|
|
||
| Video files (`.mp4`, `.mov`) are stored with Git LFS (see `.gitattributes`). When adding or replacing a video, make sure Git LFS is installed (`git lfs install`) so the file goes through the LFS filter. If a video shows up as changed in `git diff` but you didn't touch it, it was probably committed outside of LFS. Fix it by running `git add <file>` to re-add it through the filter. | ||
|
|
There was a problem hiding this comment.
As written, "Fix it by running git add <file> to re-add it through the filter" instructs the agent to stage what is really an LFS migration (it rewrites the stored blob into a pointer, a change to history), and to do it as a side effect of unrelated work. That's behavior we'd want to prevent in an agent.
| ## Videos and Git LFS | |
| Video files (`.mp4`, `.mov`) are stored with Git LFS (see `.gitattributes`). When adding or replacing a video, make sure Git LFS is installed (`git lfs install`) so the file goes through the LFS filter. If a video shows up as changed in `git diff` but you didn't touch it, it was probably committed outside of LFS. Fix it by running `git add <file>` to re-add it through the filter. | |
| ## Videos and Git LFS | |
| Video files (`.mp4`, `.mov`) are stored with Git LFS (see `.gitattributes`). When adding or replacing a video, make sure Git LFS is installed and initialized (`git lfs install`) so the file goes through the LFS filter. | |
| If a video shows up as changed in `git diff` or `git status` but you didn't touch it, that's a phantom diff: the file was committed as raw binary instead of an LFS pointer, so the clean filter now produces a pointer that differs from the stored blob. Do not stage or commit this as part of unrelated work. Running `git add` would rewrite the stored blob into a pointer, which is a real change to history. Instead, discard it with `git restore <file>`, and handle converting the file to LFS as its own deliberate change. | |
This keeps the diagnostic explanation (which is genuinely useful for the agent!), but steers toward "discard, don't silently commit" and treats the LFS conversion as an intentional, separate change.
|
@juliasilge I've reworked the guidance so that it's clear that the videos should be fixed in a separate PR from the dev's changes, and included the itemized git steps on how to fix them. I used your wording suggestions as a base and slightly reordered the README since the steps for fixing the video/lfs are hopefully not commonly needed after these remaining files are updated to lfs. |
2 participants
Summary
connections.mp4,data-explorer.mp4,positron-assistant-copytoeditor.mp4,positron-hero-fast-tour.mp4) through the LFS filter. They were committed as raw binary, which caused phantom diffs for anyone with LFS installed.Test plan