Klonowanie Git działa przez proxy, ale Git LFS zawodzi

Prześledź metadane i pobieranie obiektów Git LFS oddzielnie od klonowania Git, zanim zmienisz proxy, które poza tym działa.

Klonowanie może zakończyć przesyłanie obiektów Git, podczas gdy jego zawartość LFS wciąż brakuje. Git przechowuje pliki wskaźnikowe; klient LFS wykonuje osobne żądania dla dużych obiektów.

W dotkniętym checkoucie z zainstalowanym Git LFS sprawdź jego endpoint i ostatni błąd:

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

Przejrzyj dane wyjściowe lokalnie; adresy URL repozytoriów i logi mogą ujawniać informacje identyfikujące lub uwierzytelniające. Ustal pierwszy nieudany etap:

  1. Kontakt z API LFS.
  2. Uzyskanie akcji pobierania z Batch API.
  3. Dotarcie do adresu URL pobierania tej akcji, który może używać innego hosta przechowywania obiektów i dostarczonych nagłówków.
  4. Przesłanie treści obiektu.

Sprawdź nadpisania endpointu LFS w repozytorium, a także rzeczywisty adres URL. LFS ma własną implementację HTTP, konfigurację i odziedziczone środowisko proxy. W przypadku Git LFS 3.7.0 postępuj zgodnie z jego kolejnością wyboru proxy dla rzeczywistego adresu URL żądania. Dotarcie do zwykłego hosta Git HTTPS nie sprawdza każdej późniejszej trasy obiektów. Błąd uwierzytelniania na hoście obiektów różni się również od błędu proxy 407.

Jeśli zamierzasz wykonać pobieranie, osobne polecenie fetch w kontrolowanym repozytorium może ujawnić błąd bez kolejnego klonowania:

git -C project lfs fetch

To przenosi obiekty; nie jest to zapytanie o ustawienia tylko do odczytu. Potwierdź, że wymagana zawartość jest dostępna. Mały wskaźnik pozostający w częściowym checkoutcie nie jest dużym plikiem, a wcześniejsze udane polecenie Git nie może potwierdzić, że transfer LFS się zakończył.

Powiązane artykuły