11

I have a working copy of a repository that uses git-lfs to store some large files. I have git-lfs binary installed, but may not have run "git lfs install" inside of the working copy. When I want to update my local working copy after additions of lfs files, I execute these commands:

git pull
git lfs pull

That worked fine as long as lfs files were being added. Then the repository had some lfs files that were modified and when I ran git pull I got the error message:

Your local changes to the following files would be overwritten by merge
....
....

And it listed out all of the lfs files that were going to be modified by the pull.

Since then, I ran git lfs install inside the working copy and it worked fine, but git status still lists all those files as being modified and a git pull gives me the same error.

My question is basically, what are the right steps for updating my working copy if I'm using lfs? How do I clean up this sticky situation?

greggles
  • 2,089
  • 5
  • 20
  • 38

3 Answers3

12

Turns out that running git lfs install inside the working copy was half the solution. The second half was to run git reset inside of the working copy which:

  • left the large files in place
  • let git know that they were not actually dirty and were just fine

And now it seems that I no longer need to explicitly do the git lfs pull to get the latest large files. The first git pull works fine.

greggles
  • 2,089
  • 5
  • 20
  • 38
0

For me, before I git clone, I do git lfs install first and then git clone. Everything is solved! I think this question is very important and common there are tons of GitHub discussions without showing the true solution (at least not shown in a glance)! Thanks for your answer greggles.

user40780
  • 1,828
  • 7
  • 29
  • 50
  • If you have not yet done a git clone then this seems like a decent solution. My case was having already done a git clone and needing to pull in lfs-managed files. – greggles Feb 20 '18 at 02:58
0

I had nearly the same problem with files having an upper case file extension when working with Windows (git version 2.31.1 & git-lfs/2.13.3) and Linux (git version 2.25.1 & git-lfs/2.9.2).

My .gitattributes contained *.jpg filter=lfs diff=lfs merge=lfs -text with a lower case *.jpg and I committed files under Windows with an upper case file extension like test.JPG. After cloning the repository on a Linux system, the images with an upper case extension (.JPG) only held the reference where as the images with a lower case file extension (.jpg) got cloned as expected.
After executing a git lfs pull on the Linux system the images where located correctly on the file system but now they showed up as Modified.

The solution was to configure Git to ignore the case on Linux by running:
git config --global core.ignorecase true

Ludwig
  • 3,580
  • 2
  • 20
  • 24