CODEWITHSUNDEEP
gitgit-lfs
Samson
Samson

Reputation: 1888

git lfs cannot discard file changes (encountered files that should have been pointers)

I have a file using git lfs, but even without me doing anything, it just shows up on git as having changes. I am unable to discard these changes, whether through the VS Code UI, through git reset, or git restore.

Git keeps telling me "Encountered 1 file(s) that should have been pointers, but weren't:"

I am aware of the thread at Git error: Encountered 7 file(s) that should have been pointers, but weren't, but I have tried all the solutions there and none of them helped.

Upvotes: 19

Views: 13009

Answers (2)

Tim Baverstock
Tim Baverstock

Reputation: 568

This answer might help - it got rid of a bunch of 'changes' for me, with a checkout that compared identical to HEAD except that some of the changes were the (normalised) LFS pointers which should have been there, instead of the binary files which actually lived on the branch.

https://stackoverflow.com/a/14515846/10348047

## create a stand-alone, tagged, empty commit
true | git mktree | xargs git commit-tree | xargs git tag empty

## clear the working copy
git checkout empty

## go back to where you were before
git checkout master (or whatever)

Upvotes: 1

bk2204
bk2204

Reputation: 76579

This is a limitation of Git caused by the fact that someone committed a file that's tracked by Git LFS without using Git LFS. The Git FAQ mentions this briefly.

This occurs because when a file is marked modified in the working tree, Git runs it through the clean filter (that is, Git LFS) to see if it has changed. When that happens, Git LFS turns it into a pointer file, but the file in the index is a full Git file, so it's marked as modified. Trying to use git reset --hard doesn't change things, because Git still writes it into the tree and asks Git LFS to clean it the same way, so nothing changes.

Git LFS has no control over this behavior and can't detect it because Git doesn't offer a way to indicate whether the user is running git reset --hard or not. With an otherwise clean working tree, you'll need to run git add --renormalize . and commit. After that point, the file will be turned into an LFS file and this won't occur again. Note that a commit making this change must appear on every affected branch to fix it.

If you have CI set up, you can use Git LFS 3.0.1 or above to run git lfs fsck --pointers to check that all files are properly LFS files and reject any commits that fail. You can see the manual page for more details.

Upvotes: 27

Related Questions