Git clone fungerar via proxyn, men Git LFS misslyckas

Spåra Git LFS-metadata och objektnedladdningar separat från Git-clonen innan du ändrar en proxy som annars fungerar.

En clone kan slutföra överföringen av Git-objekt medan dess LFS-innehåll fortfarande saknas. Git lagrar pekarfiler; LFS-klienten gör separata förfrågningar för de stora objekten.

I den berörda utcheckningen med Git LFS installerat, granska dess slutpunkt och senaste fel:

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

Granska utdata lokalt; repo-URL:er och loggar kan avslöja identifierande information eller autentiseringsuppgifter. Identifiera det första steget som misslyckades:

  1. Kontakta LFS-API:et.
  2. Hämta Batch-API:ets nedladdningsåtgärd.
  3. Nå nedladdnings-URL:en för den åtgärden, som kan använda en annan värd för objektlagring och medföljande rubriker.
  4. Överföra objektets innehåll.

Kontrollera åsidosättningar av LFS-slutpunkten i repo:t samt den faktiska URL:en. LFS har sin egen HTTP-implementering, konfiguration och ärvda proxymiljö. För Git LFS 3.7.0 följer du dess proxyvalsordning för den faktiska förfrågnings-URL:en. Att nå den vanliga Git HTTPS-värden testar inte varje senare objektrutt. Ett autentiseringsfel på objektvärden skiljer sig också från proxy 407.

När du avser nedladdningarna kan en separat fetch i ett kontrollerat repo avslöja felet utan en ny clone:

git -C project lfs fetch

Detta överför objekt; det är inte en skrivskyddad inställningsfråga. Bekräfta att det nödvändiga innehållet finns tillgängligt efteråt. En liten pekare som återstår i en partiell utcheckning är inte den stora filen, och ett tidigare lyckat Git-kommando kan inte fastställa att LFS-överföringen slutfördes.

Relaterade artiklar