Git-kloning fungerer gjennom proxyen, men Git LFS feiler

Spor Git LFS-metadata og objektnedlastinger separat fra Git-klonen før du endrer en ellers fungerende proxy.

En klone kan fullføre overføringen av Git-objekter mens LFS-innholdet fortsatt mangler. Git lagrer pekerfiler; LFS-klienten sender separate forespørsler for de store objektene.

I den berørte utsjekkingen med Git LFS installert, undersøk endepunktet og siste feil:

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

Gå gjennom utdataene lokalt; repo-URL-er og logger kan avsløre identifiserende eller autentiseringsinformasjon. Identifiser det første trinnet som feilet:

  1. Kontakte LFS-API-et.
  2. Hente nedlastingshandlingen til Batch-API-et.
  3. Nå nedlastings-URL-en til den handlingen, som kan bruke en annen objektlagringsvert og medsendte headere.
  4. Overføre objektets innhold.

Kontroller både overstyringer av repoets LFS-endepunkt og den faktiske URL-en. LFS har sin egen HTTP-implementasjon, konfigurasjon og arvede proxy-miljø. For Git LFS 3.7.0, følg proxyvalgrekkefølgen for den faktiske forespørsels-URL-en. Å nå den vanlige Git-HTTPS-verten utøver ikke alle senere objektruter. En autentiseringsfeil hos objektverten er også forskjellig fra proxy 407.

Når du mener nedlastingene, kan en separat fetch i et kontrollert repo avdekke feilen uten en ny klone:

git -C project lfs fetch

Dette overfører objekter; det er ikke en skrivebeskyttet innstillingsspørring. Bekreft at det nødvendige innholdet er tilgjengelig etterpå. En liten peker som blir igjen i en delvis utsjekking, er ikke den store filen, og en tidligere vellykket Git-kommando kan ikke fastslå at LFS-overføringen ble fullført.

Relaterte artikler