Git-kloon werkt via de proxy, maar Git LFS mislukt

Een kloon kan klaar zijn met het overdragen van Git-objecten terwijl de LFS-inhoud nog ontbreekt. Git slaat pointerbestanden op; de LFS-client doet afzonderlijke verzoeken voor de grote objecten.

In de getroffen checkout met Git LFS geïnstalleerd, inspecteer je het endpoint en de laatste fout:

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

Controleer de uitvoer lokaal; repository-URL's en logs kunnen identificerende of authenticatiegegevens onthullen. Bepaal de eerste mislukte fase:

1. Contact opnemen met de LFS-API.
2. De downloadactie van de Batch-API verkrijgen.
3. De download-URL van die actie bereiken, die een andere objectopslaghost en meegegeven headers kan gebruiken.
4. De objectinhoud overdragen.

Controleer zowel overschrijvingen van het LFS-endpoint van de repository als de werkelijke URL. LFS heeft een eigen HTTP-implementatie, configuratie en overgeërfde proxyomgeving. Volg voor Git LFS 3.7.0 de volgorde voor proxyselectie voor de werkelijke verzoek-URL. Het bereiken van de gewone Git-HTTPS-host doorloopt niet elke latere objectroute. Een authenticatiefout bij de objecthost staat ook los van proxy 407.

Als je de downloads bedoelt, kan een afzonderlijke fetch in een gecontroleerde repository de fout blootleggen zonder nog een kloon:

git -C project lfs fetch

Dit draagt objecten over; het is geen alleen-lezen instellingsquery. Bevestig achteraf dat de vereiste inhoud beschikbaar is. Een kleine pointer die in een gedeeltelijke checkout achterblijft, is niet het grote bestand, en een eerder geslaagd Git-commando kan niet vaststellen dat de LFS-overdracht is voltooid.