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

Question

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).

This can happen when you do a checkout that contains files which should have been been tracked by LFS as specified in .gitattributes but somehow they've been committed directly instead. Most likely you have another program managing your repository such as a git GUI or IDE.

This can be frustrating because these files appear out of nowhere and prevent you from making checkouts. As soon as you stash your changes they return! If you get stuck in this situation, a quick fix is to commit these changes on a temporary branch so that you can checkout again.

To genuinely fix this problem, make sure you've committed the files as LFS pointers. This should be as simple as using git add. Check your work using git lfs status before committing. git lfs ls-files will show what files LFS is managing.

git lfs status is misleading since it reads Git LFS objects to be committed when it really lists all changes. Files that you expect to be tracked by LFS should read something like (LFS: c9e4f4a) or (Git: c9e4f4a -> LFS: c9e4f4a) and not (Git: c9e4f4a).

By way of example, I found this to be a problem when adding image assets through Xcode 9.2 where I added "CalendarChecked.png" which it automatically added:

$ git status
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    new file:   Example/Assets.xcassets/CalendarChecked.imageset/CalendarChecked.png

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   Example/Assets.xcassets/CalendarChecked.imageset/CalendarChecked.png

$ git lfs status

Git LFS objects to be committed:

    Example/Assets.xcassets/CalendarChecked.imageset/CalendarChecked.png (Git: c9e4f4a)

Git LFS objects not staged for commit:

    Example/Assets.xcassets/CalendarChecked.imageset/CalendarChecked.png (File: c9e4f4a)

$ git add Example/Assets.xcassets/CalendarChecked.imageset/CalendarChecked.png`
$ git lfs status

Git LFS objects to be committed:

    Empty/Empty/Assets.xcassets/CalendarChecked.imageset/CalendarChecked.png (LFS: c9e4f4a)

Git LFS objects not staged for commit:

$

Neither of these solutions worked for me, but I pieced together a few sources to finally get all this fixed.

1. Push any changes you don't want to lose

   If you can... If not, or if you don't care about your changes, press on.

2. Stop Everything

   SourceTree, any servers, file explorers and browsers. Sometimes this stuff won't work if it's being used somewhere else. When in doubt, stop it - with this it's better to overkill.

   Also, go into Task Manager, force quit any bash.exe processes. Git Bash tends to hold files open after you close the window.

3. Open a Command Window (or Terminal)

   cd to your local repo.

4. Uninstall lfs

   > git lfs uninstall

   Then it'll say something like:

   Hooks for this repository have been removed.
   Global Git LFS configuration has been removed.
   

5. Reset

   > git reset --hard

   It'll go through a lot of output probably...

6. Reinstall lfs

   > git lfs install

   This may again say it found files that should have been pointers but weren't. That's OK, keep going!

7. Pull with lfs

   > git lfs pull

   Hopefully pulling with lfs will overwrite the files that got borked.

   A few of my sources said at this point their repo was working again, but not me personally. You can open SourceTree or whatever to check if you want, but you may have to start from the top if it didn't work.

8. Migrate

   The core issue here is that lfs, instead of downloading large files like audio, video, images - anything larger than 1Mb - it just points to them on a server. This is useful if you have a bunch of large files, you're not pulling down all that stuff. So your local repo is smaller and nimbler. However, through circumstances I'm not sure about, it seems possible to corrupt the pointers. I'm sure this is an issue that the lfs people are aware of and are working on, but for now we have to work it out ourselves.

   What we've done so far is

   • uninstall lfs
   • delete everything
   • reinstall lfs
   • pull everything

   So now we have all these things in our folder that are either files or pointers to files, and lfs needs to figure out if any files should be pointers and vise versa. And hopefully by performing the steps above we deleted the corrupted pointers. So we're going to perform migrate to kick off the procedure that goes through the files on the repo, and if they're greater than 1Mb, lfs is going to replace them with a pointer.

   > git lfs migrate

9. More Errors

   Here's a point at which others have stopped and said they were working again, but not me. I got an error:

   Error in git rev-list... exit status 128 fatal: bad revision '...v1.0.0'

   @guneyozsan over at a github help page, posted this final piece to the puzzle, even though it didn't fix his issue.

   > git lfs migrate info --include-ref=v1.0.0

   Notice the version matches the version that errored - v1.0.0. You will need to replace v1.0.0 with whatever version you got in your error.

   I haven't found a source on why this error occurs but my guess is that the lfs version number generated by migrate on your local repo doesn't match the source version. For me, all this started when SourceTree crashed during a push and I forced a machine reboot, and when that happens, lfs doesn't know how to deal with it, so it just gets stuck in this loop where it's trying to update, but it can't read the corrupted data. Hence the lengthy troubleshooting.

10. Stash and Pull

When you open SourceTree, you'll probably see that it wants to add all your files back. Don't do that. Stash, then pull.

And boom, the horror is hopefully over. If not, this git hub page or this one may help you more, but this is what worked for me.