Menu
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?
758
If everything is set up correctly, you can verify that git LFS is going to work properly by: git add the file(s) in question. Do one of the following: Run git lfs status and ensure the file(s) in question appear under Git LFS objects to be committed , and that they have the LFS value in parenthesis; or.
Git LFS (Large File Storage) is a Git extension developed by Atlassian, GitHub, and a few other open source contributors, that reduces the impact of large files in your repository by downloading the relevant versions of them lazily.
If you exceed the limit of 5GB, any new files added to the repository will be rejected silently by Git LFS.
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:
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.
160
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
