Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Encountered 1 file(s) that should have been pointers, but weren't #1939

Closed
cburanicz opened this issue Feb 14, 2017 · 25 comments

Comments

@cburanicz
Copy link

@cburanicz cburanicz commented Feb 14, 2017

Hi, this is my first time posting, and has been my first time using git, so please let me know if I'm making some embarrassing mistakes :)

We're using git lfs for a company project, and my computer has been the only one where lfs checkouts hang indefinitely. The branch status is marking a bunch of files dirty that dont exist. I'm getting the error;
Encountered 1 file(s) that should have been pointers, but weren't when attempting to checkout an individual file.

This issue seems similar to #1900 that is still being addressed...so there doesnt seem to be an obvious solution yet. What can I do to resolve this issue?
Doing a checkout --force with GIT_TRACE_PACKET flag returns a HUGE dump of what looks like an ASCI representation of the file ( hundreds of lines ). The command simply hangs after that.

Thank you!

@technoweenie

This comment has been minimized.

Copy link
Member

@technoweenie technoweenie commented Feb 14, 2017

Hey, thanks for the report. The problem is that you have a file that should be using LFS (according to a pattern in .gitattributes), but it isn't. The dirty git status is just converting your file to use LFS, so it should be safe to commit.

The hanging command is fixed with #1932, which is slated for LFS 2.0.0. I wanted to backport that for a new 1.5.x bugfix release though.

@cburanicz

This comment has been minimized.

Copy link
Author

@cburanicz cburanicz commented Feb 14, 2017

hey, thanks for getting back to me. I actually want to files entirely, so I can checkout another branch. I usually do a git stash, and that gives me a clean git status. but this time, stash just hangs indefinitly.
If I want to checkout another branch, but dont have a clean status, what should I do?
Thanks

@technoweenie

This comment has been minimized.

Copy link
Member

@technoweenie technoweenie commented Feb 14, 2017

Run git lfs uninstall and then git reset --hard (assuming there are no changes you want to keep!). Once you're on the branch you want, you can run git lfs install && git lfs pull to reinstate the internal git lfs hooks, and then replace any LFS pointers with the actual files from the LFS server.

@cburanicz

This comment has been minimized.

Copy link
Author

@cburanicz cburanicz commented Feb 14, 2017

ok. I'll try that next time. Funny, we couldn't find lfs uninstall, and ran into your post from almost two years ago saying LFS uninstall didnt exist. Either way, I'm sure your solution will work. I think I can close this issue. thanks so much!

@cburanicz cburanicz closed this Feb 14, 2017
@technoweenie

This comment has been minimized.

Copy link
Member

@technoweenie technoweenie commented Feb 15, 2017

Thanks for the feedback! I'll be really curious to hear your thoughts after v2.0 launches :) But don't be shy about filing further issues in the mean time.

Funny, we couldn't find lfs uninstall

Couldn't find it where? Do you mean under "High level commands" when you run just git lfs?

@cburanicz

This comment has been minimized.

Copy link
Author

@cburanicz cburanicz commented Feb 15, 2017

Tpying in "git lfs" shows the install command, but not the uninstall command in git bash!! However, I can confirm that lfs uninstall and install worked for us!

@SychevIgor

This comment has been minimized.

Copy link

@SychevIgor SychevIgor commented Nov 23, 2017

Issue still exists...
my 2 cents:
From my perspective - issue should be solved in an app, not a workaround like "turn off/on"

@git-lfs git-lfs deleted a comment Nov 27, 2017
@ricky26

This comment has been minimized.

Copy link

@ricky26 ricky26 commented Dec 8, 2017

This issue is still a problem - running in CI, if anyone doesn't install LFS and checks in an LFS-marked file as a normal binary file, the build machine gets stuck because it can't swap branch any more. There needs to be a way to checkout 'clean' (i.e. without fixing up pointers). Uninstalling and reinstalling LFS every build sounds like it could create issues for other build operations running in parallel.

@pthurmond

This comment has been minimized.

Copy link

@pthurmond pthurmond commented Dec 8, 2017

Uninstall and re-install just ain't working. My co-worker committed without having LFS installed. I think it broke everything. Now I am trying to fix this mess.

@trejkaz

This comment has been minimized.

Copy link

@trejkaz trejkaz commented Dec 11, 2017

Same situation here. Someone committed without LFS installed, uninstall command runs without complaint but then when I try to checkout the file I get the same error again.

@ttaylorr

This comment has been minimized.

Copy link
Member

@ttaylorr ttaylorr commented Dec 11, 2017

git lfs migrate import over the range of broken commits should fix the problem.

@jloudermilk

This comment has been minimized.

Copy link

@jloudermilk jloudermilk commented Dec 12, 2017

i had this problem and git lfs migrate import --include="*.file extension that is the problem file " worked!

@rajasekharnukala

This comment has been minimized.

Copy link

@rajasekharnukala rajasekharnukala commented Dec 20, 2017

Is there a permanent fix? Is there a way to push(git lfs migrate import) it to the repository hosted in github?

@ttaylorr

This comment has been minimized.

Copy link
Member

@ttaylorr ttaylorr commented Dec 21, 2017

Is there a permanent fix? Is there a way to push(git lfs migrate import) it to the repository hosted in github?

Yes! git lfs migrate import will repair your repository by migrating any blobs that should be stored with LFS to be so. You can push this to a remote via git push --all origin, or git push --all --force origin if you migrated commits that are already present on the remote.

@trejkaz

This comment has been minimized.

Copy link

@trejkaz trejkaz commented Dec 21, 2017

Is there an equivalent for people migrating away from lfs?

@ttaylorr

This comment has been minimized.

Copy link
Member

@ttaylorr ttaylorr commented Jan 3, 2018

Is there an equivalent for people migrating away from lfs?

@trejkaz: no, not currently. Something like git lfs migrate export would be certainly possible. My main concern is that it would require downloading all LFS objects that are in the migration range, which could be potentially large (to the extent that they don't fit on disk).

That said, if the total size of your objects doesn't fit on disk, I am not sure if this is a likely scenario given what I imagine the typical use-cases of LFS to be. I wonder if it would be sufficient to download all objects in range, and then do the migration.

Another thing that people would have to be aware of is that there is currently no way to communicate "I want to remove this object" over the LFS API. I think that we would have to add this (potentially in a way that is extensible or supports the idea of "object expiration") before adding a git lfs migrate export command would be useful.

@technoweenie what do you think?

@technoweenie

This comment has been minimized.

Copy link
Member

@technoweenie technoweenie commented Jan 4, 2018

I'm all for an lfs migrate export command 👍

The idea of a delete operation in the batch api kind of scares me though. It'd be really easy to blow your data away, and I don't know what the backup/undo status of other LFS servers is. I'd just rely on LFS servers providing these capabilities.

@ttaylorr

This comment has been minimized.

Copy link
Member

@ttaylorr ttaylorr commented Jan 4, 2018

I'd just rely on LFS servers providing these capabilities.

I think that that's fair. What do you think about shipping this in v2.5.0?

@sandersaares

This comment has been minimized.

Copy link

@sandersaares sandersaares commented May 23, 2018

git lfs migrate import will repair your repository by migrating any blobs that should be stored with LFS to be so

This does not seem to be the case.

Encountered 2 file(s) that should have been pointers, but weren't:
        SetupDocker/docker-ubuntu16.deb

...

git lfs track *.deb
"*.deb" already supported

...

git lfs migrate import
migrate: Fetching remote refs: ..., done
migrate: Sorting commits: ..., done
migrate: Rewriting commits: 100% (0/0), done
migrate: Updating refs: ..., done
migrate: checkout: ..., done

...

git push --all
Locking support detected on remote "origin". Consider enabling it with:
  $ git config lfs.https://xxx.visualstudio.com/xxx.git/info/lfs.locksverify true
Everything up-to-date
...


@ttaylorr

This comment has been minimized.

Copy link
Member

@ttaylorr ttaylorr commented May 23, 2018

@sandersaares presently, you must specify the patterns that you wish git lfs migrate to pick up, i.e., git lfs migrate import --everything --include='*.deb'. I think that reading the .gitattribute(s) in a repository if no --include argument is given would be an interesting pull request, and I'd be happy to mentor someone through that if anyone has interest.

@subatomicglue

This comment has been minimized.

Copy link

@subatomicglue subatomicglue commented Jul 5, 2018

Is there a way to have *.png for git-lfs, but exclude a single myfile.png to go into normal git? My problem is that the htmlpreview on github.io doesn't work with git-lfs, and I want one of my images to show in the preview (but still want .png rules for other images, if I ever add them)...

So I added/pushed myfile.png to git without the *.png .gitattribute, then re-added the *.png .gitattribute for future .png adds. So now myfile.png works in htmlpreview... :)

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

Is getting annoying for this file, because I actually want it in git, not in LFS... :( I can't ignore this error. Normally, I can see how useful this helpful message would be though.

@ttaylorr

This comment has been minimized.

Copy link
Member

@ttaylorr ttaylorr commented Jul 5, 2018

Is there a way to have *.png for git-lfs, but exclude a single myfile.png to go into normal git?

Certainly. You can accomplish this with:

$ git lfs migrate import --everything --include='*.png' --exclude='myfile.png'
@subatomicglue

This comment has been minimized.

Copy link

@subatomicglue subatomicglue commented Jul 5, 2018

That helped, I ended up adding myfile.png -filter -diff -merge -text to the end of my .gitattributes. order seems to matter, and adding to the end overrides the general filter. Thanks!

To avoid this hell:

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

I just had to git rm the file and commit/push (or probably git add, but I didn't want to add it to lfs), otherwise I was caught in a weird merge hell loop, where I could never rebase --continue or --skip.

@PointedEars

This comment has been minimized.

Copy link

@PointedEars PointedEars commented Sep 27, 2018

@sandersaares presently, you must specify the patterns that you wish git lfs migrate to pick up, i.e., git lfs migrate import --everything --include='*.deb'. I think that reading the .gitattribute(s) in a repository if no --include argument is given would be an interesting pull request, and I'd be happy to mentor someone through that if anyone has interest.

Thanks a lot. I do not know if I have time for the pull request, but I have written a working solution using (ba)sh and (g)awk:

git lfs migrate import --everything$(awk '/filter=lfs/ {printf " --include='\''%s'\''", $1}' .gitattributes)

(You can test it with echo git lfs migrate import --everything$(awk '/filter=lfs/ {printf " --include='\''%s'\''", $1}' .gitattributes).)

Can this be integrated?

@ttaylorr

This comment has been minimized.

Copy link
Member

@ttaylorr ttaylorr commented Sep 28, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.