Git error: Encountered 7 file(s) that shou

Question

How to clean repo, if staged files marked as modified

after

git reset --hard

I get

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

git clean -fdx

doesn't help too

Answer 1

This happens 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. The likely cause is that you have another program managing your repository such as a git GUI or IDE.

To fix this make sure you've committed the files as LFS pointers. This should be as simple as using git add. You can 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. What you're looking for is that a file that you expect to be tracked by LFS reads 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:   Empty/Empty/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:   Empty/Empty/Assets.xcassets/CalendarChecked.imageset/CalendarChecked.png

$ git lfs status

Git LFS objects to be committed:

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

Git LFS objects not staged for commit:

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

$ git add Empty/Empty/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:

As you have no doubt experienced, this is frustrating because these files that appear out of nowhere 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.

Answer 2

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

git lfs uninstall

git reset --hard

git lfs install

git lfs pull

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

Try the following commands:

git rm --cached -r .

git reset --hard

git rm .gitattributes

git reset .

git checkout .

This worked for me!

Answer 3

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

   Make sure you're in your main branch, and everything is committed (except the bad files).

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.

   If you go through all this and your changes aren't sticking, consider restarting your computer, force-stopping anything from TaskManager that might affect your repo and trying again.

3. Open a Command Window (or Terminal)

   On Windows, this is going to be a cmd or command window. If you're not sure, click the windows key, and type cmd. It'll suggest Command Prompt, click that.

   cd to your 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...

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 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 tracks large files by replacing them with pointers. _{^{If you're a programmer this is similar to how a variable points to a place in memory, rather than holding the actual value.}}

   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 herein is the source of our horrific error - some files should have been pointers but weren't). 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 Horror

   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'

   There is a tragic hero, @guneyozsan over at a github help page, who posted this final piece to the puzzle even though it didn't fix his issue. He posted it about 2 hours before I started looking for the zillionthth time on how to fix this, even though the issue has been around for 2 years. Bless you @guneyozsan, and I wish you luck in resolving your issue.

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

   Notice the version matches the version that errored - v1.0.0.

   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 whatever reason, the local lfs data was screwed up (for me, all this started when SourceTree crashed during a push and I forced a machine reboot, so that may have corrupted the lfs data), and when that happens, SourceTree 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 over. Hopefully. If not, this git hub page or this one may help you more, but this is what worked for me.

Answer 4

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.