Git Pull – Smudge-Filter-LFS fehlgeschlagen

Lesezeit: 7 Minuten

Git Pull Smudge Filter LFS fehlgeschlagen
Jack

Ich versuche, Code von Github auf unseren Server zu ziehen (git pull origin master).

Das hat vorher funktioniert. Allerdings bekomme ich jetzt folgende Fehlermeldung:

$ 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

Ich habe den gleichen Befehl mit ausgeführt 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

Ich habe überprüft, dass meine ssh-Anmeldeinformationen korrekt sind:

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

Und in der Tat weiß ich, dass die Anmeldeinformationen in Ordnung sind, weil die pull wird die herunterbringen .gitattributes Datei (zusammen mit anderen kleinen Dateiänderungen, die ich vorgenommen habe):

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

Ich habe überprüft, dass Git LFS korrekt konfiguriert zu sein scheint:

$ 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
...

ich habe das gefunden Github-Problemund ich habe alle drei Schritte ausprobiert:

$ 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

Im ersten Schritt wurde nach meinem Benutzernamen gefragt. Wie es heißt, scheint Git LFS also nichts zwischenzuspeichern.

Ich habe nicht viel Erfahrung mit Git LFS, und ehrlich gesagt habe ich keine Ideen mehr, wie ich dieses Problem angehen soll.

Es gibt zwei Aktionen, die ich kürzlich durchgeführt habe und die möglicherweise etwas kaputt gemacht haben:

  1. Ich habe einen Benutzer aus unserem Repository entfernt. Der ssh-Schlüssel des Servers gehörte dem Benutzer. Wir haben einen Bereitstellungsschlüssel hinzugefügt, aber das habe ich gelesen Git LFS unterstützte keine Bereitstellungsschlüssel (obwohl es scheint, dass die Unterstützung kürzlich hinzugefügt wurde). Also haben wir auf einen Benutzerschlüssel umgestellt. Beide Schlüssel wurden mit bestätigt ssh -T git@github.com Prüfung. Vielleicht gibt es trotzdem ein Authentifizierungsproblem?
  2. Ich habe das Repository auf einen Server ohne Git LFS heruntergezogen. Ich habe es damals nicht bemerkt, aber die auf den Zielserver übertragenen Dateien sind in Ordnung. Aber vielleicht hat dies etwas im Repository kaputt gemacht?

Jede Hilfe, die Sie leisten könnten, wäre sehr willkommen.

PS – Es tut mir leid, wenn meine Anonymisierung Verwirrung stiftet. Ich habe unsere tatsächliche IP-Adresse durch ersetzt X.X.X.X; unser Organisationsname mit org-name; unser Repo-Name mit repo-name; unser Github-Benutzer mit user-name; den Dateinamen mit file.msi; und noch ein paar Sachen.

BEARBEITEN 16.05.17: Sprache hinzugefügt, um deutlich zu machen, dass es früher funktioniert hat … und dass ich es kaputt gemacht habe.

1647208087 848 Git Pull Smudge Filter LFS fehlgeschlagen
Enkel

In meinem Fall wurde das SSH-authentifizierte Repository aktualisiert, um LFS von einem anderen Client zu verwenden, und auf meiner Seite wusste Git-LFS nichts über die SSH-Remote-URL. Was ich getan habe, um es zu beheben, war Folgendes:

Kopieren Sie die konfigurierte URL in remote.origin.url (Push-URL für origin) zu lfs.url (die URL, die LFS verwendet):

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

(Falls Ihre Fernbedienung nicht benannt ist origin ändern Sie dann zu Ihrem entfernten Namen.)

Dann renne

$ git config lfs.url

um die URL anzuzeigen und zu bestätigen, dass sie tatsächlich eine SSH-URL und keine HTTP/HTTPS-URL enthält.

Dann kannst du

$ git pull

Getan.


Wenn du hast es vorher vermasselt und master und orgin/master irgendwie auseinander gegangen wie bei mir war das dann evtl. nötig git checkout -fB master origin/master (das fragt nicht und überschreibt die lokale Version des Master-Zweigsdamit Vorsicht und sorgfältig ausführen!).

Siehe auch: https://github.com/git-lfs/git-lfs/issues/2661#issuecomment-335903332

  • Danke für die Antwort @Enkelkind. Am Ende brauchten wir nur ein oder zwei Stunden, um die Binärdateien auf den Server zu verschieben scp, und wir arbeiten an der Implementierung eines Dateiserversystems wie S3 anstelle von Git LFS. Ich werde fortfahren und dies als Antwort markieren, da es ein ähnliches Problem für Sie gelöst hat. Ich habe es irgendwie umgangen, haha. Danke für die Antwort!

    – Jack

    22. Februar 2018 um 17:31 Uhr

  • Das war’s! Beachten Sie auch – wenn Sie von einer anderen Fernbedienung ziehen, passen Sie sie an git config remote.origin.url zu git config remote.<MY_OTHER_REMOTE>.url.

    – Tomasz Gandor

    17. Mai 2018 um 9:26 Uhr

  • Verstehe ich es also richtig, dass sich GIT LFS nicht um die Remote-URL kümmert und stattdessen die Remote-URL des Repositorys verwendet, in dem es eingerichtet wurde? Ist dies ein Fehler oder ein Feature von GIT LFS?

    – Florian Winter

    10. Oktober 2019 um 13:13 Uhr

  • @FlorianWinter Ich denke, es ist eher Git LFS einfach hat nicht eine URL auf Abruf, wenn das Repository geklont wurde, als für das Repository LFS nicht aktiviert war. Wenn Sie ein Repository mit bereits aktiviertem LFS klonen, stelle ich mir vor, dass die oben erläuterte Konfigurationseinstellung genauso gesetzt wird, nur automatisch.

    – Enkel

    10. Oktober 2019 um 13:42 Uhr


  • Das ist mir mit einem frisch geklonten Repository passiert. Jemand anderes hat GIT LFS darauf eingerichtet, lange bevor ich es geklont habe. @grandchild Ich werde jedoch selbst weiter recherchieren, wenn ich es noch reproduzieren kann / Zeit dazu habe. Danke.

    – Florian Winter

    10. Oktober 2019 um 13:53 Uhr

In meinem Fall muss ich einen weiteren Schritt hinzufügen, nachdem ich die Anweisungen der Antwort von @grandchild befolgt habe. Wie von @grandchild erklärt, wurde mein Remote-Git-Repo kürzlich so geändert, dass es das Protokoll ssh vom ursprünglichen https verwendet. In meiner Git-Konfiguration war die Git-Konfiguration “http.sslverify” ursprünglich nicht festgelegt. Ich glaube, der Standardwert ist wahr, wenn er fehlt. Es verursachte den Fehler “Smudge Filter lfs failed”. Einmal habe ich es auf false gesetzt

$ git config http.sslverify falsch

Es funktioniert ohne Fehler.

  • Dadurch wird die Überprüfung des SSL-Zertifikats übersprungen, was im Allgemeinen keine gute Idee ist. Sie sollten untersuchen, warum die Zertifikatsprüfung überhaupt fehlschlägt. Wenn Sie mit selbstsignierten Zertifikaten arbeiten (was wahrscheinlich die einzige gültige Kurzzeitausrede ist, um die Überprüfung zu deaktivieren), schauen Sie sich an git-scm.com/docs/git-config#EXAMPLES (gegen Ende dieses Abschnitts). Sie können die Prüfung nur für eine URL deaktivieren.

    – Enkel

    10. Februar 2021 um 23:18 Uhr


  • @grandchild Wie ich in meinem Kommentar erwähnt habe, wurde der Fehler durch die kürzlich erfolgte Änderung des Verbindungsprotokolls von https auf ssh in unserem Remote-Repository verursacht. Die Änderung ist bei http.sslverify fehlgeschlagen, da sie in unserem Remote-Repository nicht mehr unterstützt wird.

    – Feng-Yang

    12. Februar 2021 um 20:20 Uhr


999100cookie-checkGit Pull – Smudge-Filter-LFS fehlgeschlagen

This website is using cookies to improve the user-friendliness. You agree by using the website further.

Privacy policy