Git Pull - Échec du filtre de tache LFS
J'essaie d'extraire du code sur notre serveur à partir de Github (git pull Origin master).
Cela fonctionnait auparavant. Cependant, maintenant, je reçois l'erreur suivante:
$ 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
J'ai exécuté la même commande avec 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' '[email protected]' '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
J'ai vérifié que mes informations d'identification ssh sont correctes:
$ ssh -T [email protected]
Hi user-name! You've successfully authenticated, but GitHub does not provide Shell access.
Et, en fait, je sais que les informations d'identification sont correctes, car le pull fera baisser le .gitattributes fichier (avec d'autres petits changements de fichiers que j'ai faits):
file.msi filter=lfs diff=lfs merge=lfs -text
J'ai vérifié que Git LFS semble être configuré correctement:
$ 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
...
J'ai trouvé cela problème Github , et j'ai essayé les trois étapes:
$ 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
La première étape a demandé mon nom d'utilisateur. Donc, comme il est dit, il ne semble pas que Git LFS mette en cache quoi que ce soit.
Je n'ai pas beaucoup d'expérience avec Git LFS, et franchement, je suis à court d'idées sur la façon d'aborder ce problème.
Il y a deux actions que j'ai prises récemment qui pourraient avoir cassé quelque chose:
- J'ai supprimé un utilisateur de notre référentiel. La clé ssh du serveur appartenait à l'utilisateur. Nous avons ajouté une clé de déploiement, mais j'ai lu que Git LFS ne supportait pas les clés de déploiement (bien qu'il semble que le support ait été ajouté récemment). Nous sommes donc passés à une clé utilisateur. Les deux clés ont été confirmées par le
ssh -T [email protected]test. Pourtant, il y a peut-être un problème d'authentification? - J'ai tiré le référentiel sur un serveur sans Git LFS. Je ne m'en rendais pas compte à l'époque, mais les fichiers transférés sur le serveur de destination vont bien. Cependant, peut-être que cela a cassé quelque chose dans le référentiel?
Toute aide que vous pourriez apporter serait grandement appréciée.
PS - Je suis désolé si mon anonymat crée de la confusion. J'ai remplacé notre adresse IP réelle par X.X.X.X; le nom de notre organisation avec org-name; notre nom de repo avec repo-name; notre utilisateur Github avec user-name; le nom du fichier avec file.msi; et quelques autres choses.
EDIT 16/05/17: Ajout d'un langage pour indiquer clairement que cela fonctionnait ... et que je l'ai cassé.
Dans mon cas, le référentiel authentifié SSH a été mis à jour pour utiliser LFS à partir d'un autre client et de mon côté, Git-LFS ne connaissait pas l'URL à distance SSH. Ce que j'ai fait pour y remédier était le suivant:
Copiez l'URL configurée dans remote.Origin.url (Pousser l'URL pour Origin) vers lfs.url (l'URL utilisée par LFS):
$ git config lfs.url $(git config remote.Origin.url)
(Si votre télécommande n'est pas nommée Origin, remplacez-la par votre nom de télécommande.)
Exécutez ensuite
$ git config lfs.url
pour afficher l'URL et confirmer qu'elle contient bien une URL SSH, et non une URL HTTP/HTTPS.
Ensuite vous pouvez
$ git pull
Terminé.
Si vous avez foiré avant et master et orgin/master ont en quelque sorte divergé comme ce fut le cas pour moi, alors vous devrez peut-être git checkout -fB master Origin/master (cela ne demande pas et écrase la version locale de la branche master , donc méfiez-vous et exécutez soigneusement !).
Voir aussi: https://github.com/git-lfs/git-lfs/issues/2661#issuecomment-335903332