30

I'm attempting to pull code onto our server from Github (git pull origin master).

This worked before. However, now, I'm receiving the following error:

$ git pull origin master
From github.com:org-name/repo-name
 * branch              master     -> FETCH_HEAD
Updating 8024663e..e458e5c1
fatal: path/to/file.msi: smudge filter lfs failed

I ran the same command with GIT_TRACE=1:

$ GIT_TRACE=1 git pull origin master
19:25:26.331064 git.c:371               trace: built-in: git 'pull' 'origin' 'master'
19:25:26.333947 run-command.c:350       trace: run_command: 'fetch' '--update-head-ok' 'origin' 'master'
19:25:26.334661 exec_cmd.c:116          trace: exec: 'git' 'fetch' '--update-head-ok' 'origin' 'master'
19:25:26.337625 git.c:371               trace: built-in: git 'fetch' '--update-head-ok' 'origin' 'master'
19:25:26.344457 run-command.c:350       trace: run_command: 'ssh' 'git@github.com' 'git-upload-pack '\''org-name/repo-name.git'\'''
19:25:26.925565 run-command.c:350       trace: run_command: 'rev-list' '--objects' '--stdin' '--not' '--all' '--quiet'
19:25:26.937016 run-command.c:350       trace: run_command: 'rev-list' '--objects' '--stdin' '--not' '--all' '--quiet'
19:25:26.937833 exec_cmd.c:116          trace: exec: 'git' 'rev-list' '--objects' '--stdin' '--not' '--all' '--quiet'
19:25:26.941292 git.c:371               trace: built-in: git 'rev-list' '--objects' '--stdin' '--not' '--all' '--quiet'
From github.com:org-name/repo-name
 * branch              master     -> FETCH_HEAD
19:25:26.994717 run-command.c:1130      run_processes_parallel: preparing to run up to 1 tasks
19:25:26.994880 run-command.c:1162      run_processes_parallel: done
19:25:26.995780 run-command.c:350       trace: run_command: 'gc' '--auto'
19:25:26.996735 exec_cmd.c:116          trace: exec: 'git' 'gc' '--auto'
19:25:27.000596 git.c:371               trace: built-in: git 'gc' '--auto'
19:25:27.002716 run-command.c:350       trace: run_command: 'merge' 'FETCH_HEAD'
19:25:27.003445 exec_cmd.c:116          trace: exec: 'git' 'merge' 'FETCH_HEAD'
19:25:27.006078 git.c:371               trace: built-in: git 'merge' 'FETCH_HEAD'
Updating 8024663e..e458e5c1
19:25:27.420945 run-command.c:350       trace: run_command: 'git-lfs filter-process'
19:25:27.470865 run-command.c:209       trace: exec: '/bin/sh' '-c' 'git-lfs filter-process' 'git-lfs filter-process'
trace git-lfs: run_command: 'git' version
trace git-lfs: run_command: 'git' config -l
trace git-lfs: Initialize filter-process
trace git-lfs: Read filter-process request.
trace git-lfs: Read filter-process request.
fatal: path/to/file.msi: smudge filter lfs failed
19:25:27.998635 run-command.c:42        trace: run_command: running exit handler for pid 18022

I verified my ssh credentials are correct:

$ ssh -T git@github.com
Hi user-name! You've successfully authenticated, but GitHub does not provide shell access.

And, in fact, I know the credentials are ok, because the pull will bring down the .gitattributes file (along with other small file changes I've done):

 file.msi filter=lfs diff=lfs merge=lfs -text

I verified Git LFS appears to be configured correctly:

$ git config -l
filter.lfs.process=git-lfs filter-process
filter.lfs.required=true
filter.lfs.clean=git-lfs clean -- %f
filter.lfs.smudge=git-lfs smudge -- %f
...

I found this Github issue, and I tried all three steps:

$ echo "protocol=https\nhost=github.com" | git credential fill
$ echo "protocol=https\nhost=github.com" | git credential fill | git credential reject
$ echo "protocol=https\nhost=github.com" | git credential fill | git credential approve

The first step asked for my username. So, as it says, it doesn't appear that Git LFS is caching anything.

I don't have much experience with Git LFS, and frankly, I am out of ideas on how to approach this problem.

There are two actions I took recently that might have broken something:

  1. I removed a user from our repository. The server's ssh key belonged to the user. We added a deployment key, but I read that Git LFS didn't support deployment keys (although, it appears that support was added recently). So, we switched to a user key. Both keys were confirmed with the ssh -T git@github.com test. Still, perhaps there's an authentication issue?
  2. I pulled the repository down onto a server without Git LFS. I didn't realize it at the time, but the files transferred to the destination server fine. However, perhaps this broke something in the repository?

Any help you could lend would be greatly appreciated.

PS - I'm sorry if my anonymizing creates confusion. I replaced our actual IP address with X.X.X.X; our organization name with org-name; our repo name with repo-name; our Github user with user-name; the file name with file.msi; and, a few more things.

EDIT 5/16/17: Added language to make it clear that it used to work... and that I broke it.

Jack
  • 303
  • 1
  • 3
  • 6

3 Answers3

42

In my case the SSH-authenticated repository was updated to use LFS from another client and on my side Git-LFS didn't know about the SSH remote-url. What I did to fix it was the following:

Copy the URL configured in remote.origin.url (push URL for origin) to lfs.url (the URL LFS uses):

$ git config lfs.url $(git config remote.origin.url)

(If your remote is not named origin then change to your remote name.)

Then run

$ git config lfs.url

to show the URL and confirm that it does indeed contain an SSH url, and not some HTTP/HTTPS url.

Then you can

$ git pull

Done.

If you screwed up before and main and orgin/main have somehow diverged as was the case for me then you might need to git checkout -fB main origin/main (this doesn't ask and overwrites the local version of the main branch, so beware and execute carefully!).

See also: https://github.com/git-lfs/git-lfs/issues/2661#issuecomment-335903332

grandchild
  • 1,157
  • 15
  • 20
  • 1
    Thanks for the answer @grandchild. We ended up just taking an hour or two to move the binary files to the server using `scp`, and we're working on implementing a file server system like S3 instead of Git LFS. I'll go ahead and mark this as the answer, since it solved a similar problem for you. I kind of went around it haha. Thanks for the answer! – Jack Feb 22 '18 at 17:31
  • That was it! Also note - if you're pulling from a different remote, adjust `git config remote.origin.url` to `git config remote..url`. – Tomasz Gandor May 17 '18 at 09:26
  • So do I understand it correctly that GIT LFS doesn't care about the remote URL and instead uses the remote URL of the repository in which it was set up? Is this a bug or a feature of GIT LFS? – Florian Winter Oct 10 '19 at 13:13
  • @FlorianWinter I think it's more that Git LFS simply *does not have* a URL on pull, if the repository was cloned when the repository didn't have LFS enabled. If you clone a repository with LFS already enabled, I imagine the config setting explained above will be set just the same, just automatically. – grandchild Oct 10 '19 at 13:42
  • This happened to me with a freshly cloned repository. Someone else set up GIT LFS on it long before I cloned it. @grandchild However, I will do more research on my own if I can still reproduce it / have time to do so. Thanks. – Florian Winter Oct 10 '19 at 13:53
1

In my case, I have to add one more step after following the instructions provided by the answer by @grandchild. As explained by @grandchild, my remote git repo was changed to use protocol ssh from original https recently. In my git configuration, git configuration "http.sslverify" was not set originally. I believe the default value is true if it is missing. It caused the error "smudge filter lfs failed". Once I set it to false

$ git config http.sslverify false

It works without errors.

Feng Yang
  • 67
  • 5
  • 2
    This skips SSL certificate verification, which is not a good idea in general. You should investigate why the certificate check fails in the first place. When working with self-signed certificates (which is probably the only valid short-time excuse for disabling verification) have a look at https://git-scm.com/docs/git-config#EXAMPLES (towards the end of that section). You can disable the check for just one URL. – grandchild Feb 10 '21 at 23:18
  • 1
    @grandchild As I mentioned in my comment, the failure was caused by recent change of connection protocol, from https to ssh, in our remote repository. The change failed the http.sslverify since it is no longer supported in our remote repository. – Feng Yang Feb 12 '21 at 20:20
1

For me, the solution appears to have been updating Git LFS to the latest version.

Immortaly007
  • 33
  • 6