Git error: Encountered 7 file(s) that should have been pointers, but weren't

Like Travis Heeter mentioned in his answer, Try the following command sequence:

git lfs uninstall
git reset --hard
git lfs install
git lfs pull

In case if this is not working (because this was not working for me), the following hack may work:

git rm --cached -r .
git reset --hard
git rm .gitattributes
git reset .
git checkout .

This worked for me!

I had this exact error with some files stored with git-LFS and solved it the same way I've solved a linending induced borked index .

Clear the cache and do a hard reset:

git rm --cached -r .
git reset --hard

This was significantly faster than a fresh clone for me due to the huge git-LFS files in my repo.

Since git lfs 2.5.0, there is a new command available that makes this easier (docs):

git lfs migrate import --no-rewrite "broken file.jpg" "another broken file.png" ...

This "migrates" files to git lfs which should be in lfs as per .gitattributes, but aren't at the moment (which is the reason for your error message).

--no-rewrite prevents git from applying this to older commits, it creates a single new commit instead.

Use -m "commitmessage" to set a commitmessage for that commit.

The problem comes from the mismatch beetween the filetypes marked as to be tracked by git LFS in the .gitattributes and some matching files already under conventional non-LFS version control.

So the simplest workaround here is to just remove the .gitattributes file for a moment:

git rm .gitattributes
git reset .
git checkout .

Afterwards you can checkout any other branch.

One more advice: When adding a new filetype to git LFS, prefer not to do this by hand by modifying the .gitattributes but e.g. by running:

git lfs track PATTERN

where PATTERN is the pattern for matching files, e.g *.so

This way all already non-LFS versioned files matching the new tracking-pattern will be marked dirty and can be simlpy added, i.e. converted to git LFS (file pointers).