Git-Clone funktioniert über den Proxy, aber Git LFS schlägt fehl

Ein Clone kann die Übertragung der Git-Objekte abschließen, während dessen LFS-Inhalt noch fehlt. Git speichert Pointer-Dateien; der LFS-Client stellt separate Anfragen für die großen Objekte.

Untersuchen Sie im betroffenen Checkout mit installiertem Git LFS dessen Endpunkt und den letzten Fehler:

git -C project lfs env
git -C project lfs logs last

Prüfen Sie die Ausgabe lokal; Repository-URLs und Logs können identifizierende Informationen oder Authentifizierungsdaten preisgeben. Identifizieren Sie die erste fehlgeschlagene Stufe:

1. Kontaktaufnahme mit der LFS-API.
2. Abrufen der Download-Aktion der Batch-API.
3. Erreichen der Download-URL dieser Aktion, die einen anderen Objektspeicher-Host und mitgelieferte Header verwenden kann.
4. Übertragen des Objektinhalts.

Prüfen Sie Überschreibungen des LFS-Endpunkts im Repository ebenso wie die tatsächliche URL. LFS hat eine eigene HTTP-Implementierung, Konfiguration und geerbte Proxy-Umgebung. Befolgen Sie für Git LFS 3.7.0 dessen Reihenfolge der Proxy-Auswahl für die tatsächliche Anforderungs-URL. Das Erreichen des gewöhnlichen Git-HTTPS-Hosts prüft nicht jede spätere Objektroute. Ein Authentifizierungsfehler am Objekt-Host ist ebenfalls von Proxy 407 zu unterscheiden.

Wenn Sie die Downloads beabsichtigen, kann ein separater Fetch in einem kontrollierten Repository den Fehler ohne einen weiteren Clone aufdecken:

git -C project lfs fetch

Dies überträgt Objekte; es ist keine schreibgeschützte Abfrage von Einstellungen. Bestätigen Sie anschließend, dass der erforderliche Inhalt verfügbar ist. Ein kleiner Pointer, der in einem partiellen Checkout verbleibt, ist nicht die große Datei, und ein früherer erfolgreicher Git-Befehl kann nicht belegen, dass die LFS-Übertragung abgeschlossen wurde.