Git clone přes proxy funguje, ale Git LFS selhává

Sledujte metadata a stahování objektů Git LFS odděleně od klonu Git, než začnete měnit jinak funkční proxy.

Klon může dokončit přenos objektů Git, zatímco obsah LFS stále chybí. Git ukládá soubory s ukazateli; klient LFS posílá samostatné požadavky na velké objekty.

V postiženém checkoutu s nainstalovaným Git LFS zkontrolujte jeho endpoint a poslední selhání:

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

Výstup posuzujte lokálně; URL repozitáře a protokoly mohou odhalit identifikační nebo autentizační údaje. Určete první fázi, která selhala:

  1. Kontaktování LFS API.
  2. Získání akce stahování z Batch API.
  3. Dosažení adresy URL pro stahování této akce, která může používat jiného hostitele objektového úložiště a dodané hlavičky.
  4. Přenos těla objektu.

Zkontrolujte přepsání endpointu LFS v repozitáři i skutečnou adresu URL. LFS má vlastní implementaci HTTP, konfiguraci a zděděné proxy prostředí. Pro Git LFS 3.7.0 postupujte podle jeho pořadí výběru proxy pro skutečnou adresu URL požadavku. Dosažení běžného hostitele Git HTTPS nepokryje všechny pozdější trasy objektů. Selhání autentizace na hostiteli objektů se také liší od proxy 407.

Pokud stahování zamýšlíte, samostatný fetch v kontrolovaném repozitáři může selhání odhalit bez dalšího klonu:

git -C project lfs fetch

Tím se přenášejí objekty; nejde o dotaz na nastavení pouze pro čtení. Poté ověřte, že je požadovaný obsah dostupný. Malý ukazatel, který zůstane v částečném checkoutu, není velký soubor a dřívější úspěšný příkaz Git nemůže prokázat, že přenos LFS byl dokončen.

Související články