Git error: Encountered 7 file(s) that should have been pointers, but weren't
How to clean repo, if staged files marked as modified
git reset --hard
Encountered 7 file(s) that should have been pointers, but weren't:
git clean -fdx
doesn't help too
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.
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!
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. File 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.
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).
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.
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.
> git lfs uninstall
Then it'll say something like:
Hooks for this repository have been removed. Global Git LFS configuration has been removed.
> git reset --hard
It'll go through a lot of output...
> git lfs install
This may again say it found files that should have been pointers but weren't. That's OK, keep going!
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.
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
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.
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.
Ensure you have git lfs version 2.5 or higher installed (download here).
Check you are using the git lfs version you downloaded (2.7.7 for me):
>git lfs version git-lfs/2.7.2
git lfs migrate import --fixup --everything
Pull your branch and fix any merge conflicts.
Found in this github comment.
When it is obviously an error that shows up out of nowhere, this is what we do in our team:
Disable lfs for that specific type file (modifying .gitattributes or via SourceTree menus)
The change will dissapear and you will see a change on .gitattributes instead
Remove the problem:
3.1 One solution is to execute git reset --hard. Another way, discard changes. Sometimes the file will not come up again.
3.2.1 If the previous solution doesn't work, repeat 1 and 2. Then make sure that this branch you are in (A) has already commited and pushed everything except those annoying files. Then commit your change, but not push.
3.2.2: Go to another branch (B)
3.2.3: Remove that local branch (A) where you performed the commit to .gitattributes, forcing the removal even when it says there's a commit that hasn't been pushed. It will forget that commit (it can afterwards be removed via GC or whatever but it's not a big deal if the file that has the error is not huge)
3.2.4: Checkout the branch A again. It will download the previous status of the repository without the annoying files and LFS settings set up the correct way.
That always works!
The following process will add a commit which replaces all binary files that should be lfs pointers with lfs pointers.
Clean working copy completely. Together with the force add below this prevents any files getting added or removed due to .gitignore patterns.
git clean -dfx git reset --hard git checkout -- .
Add remove for everything to staging area. Working copy will not be touched.
git rm --cached -r .
Readd all files from working copy again. This will basically undo the previous command but will reevaluate lfs filters. Use -f to ignore .gitignore. All files present were previously checked in and should get added again.
git add -f .
You staging area now should only contain the binary files that previously raised the 'should have been pointers' error.
git commit -m "moved files to lfs"
One possible cause for this error is due to git LFS-related changes to .gitattributes that impacts already added files in a repo.
(I'm not sure of the exact steps to reproduce, but the issue seemed to occur when I touched a file that was newly affected by the .gitattributes that was previously committed as a non-LFS file that should now be an LFS file. The issue seemed aggravated by switching branches, or at least made it impossible to switch branches until the issue was resolved.)
In this case, I used the steps below to prevent this error from occurring repeatedly.
- Fix the issue for the branch you are on by following one of the other answers here (e.g. to clear the cache and reset. I found BheeMa's answer to be effective.)
- Go to your main branch, and ensure there is nothing to commit with git status
- Force git to recheck and "reapply" git attributes changes
git rm --cached -r . git add -A
Warning: make sure in step 2 that there was nothing to commit, as the steps above will add any files that were not previously versioned
- Verify the results with git status (it should only have modified relevant files to become LFS pointers, i.e. files that can potentially cause the "encountered files that should have been pointers" error) and commit changes
- (Optionally, merge/rebase this fix to all other branches if possible. Otherwise, this error could pop up again when switching to those branches. Note that it may be necessary to repeat the initial fix for each branch as per step 1 to be safe, though it could be ok just to commit the affected files.)
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.