Git-kloon werk deur die proxy, maar Git LFS misluk

Volg Git LFS se metadata- en objekaflaaie afsonderlik van die Git-kloon voordat jy 'n andersins werkende proxy verander.

'n Kloon kan klaar wees met die oordrag van Git-objekte terwyl die LFS-inhoud steeds ontbreek. Git stoor wyserlêers; die LFS-kliënt maak afsonderlike versoeke vir die groot objekte.

In die betrokke werkkopie met Git LFS geïnstalleer, ondersoek die eindpunt en die laaste fout:

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

Hersien die uitvoer plaaslik; repository-URL's en logs kan identifiserende of verifikasie-inligting blootlê. Identifiseer die eerste mislukte stap:

  1. Kontak die LFS API.
  2. Verkry die aflaaiaksie van die Batch API.
  3. Bereik daardie aksie se aflaai-URL, wat 'n ander objekberging-gasheer en verskafde koptekste kan gebruik.
  4. Dra die objekliggaam oor.

Kontroleer die repository se LFS-eindpunt-oorheersings sowel as die werklike URL. LFS het sy eie HTTP-implementering, konfigurasie en geërfde proxy-omgewing. Vir Git LFS 3.7.0, volg sy proxy-keuseorde vir die werklike versoek-URL. Om die gewone Git HTTPS-gasheer te bereik, beoefen nie elke latere objekroete nie. 'n Objekgasheer-verifikasiefout verskil ook van proxy 407.

Wanneer jy die aflaaie bedoel, kan 'n aparte fetch in 'n beheerde repository die fout blootlê sonder nog 'n kloon:

git -C project lfs fetch

Dit dra objekte oor; dit is nie 'n leesalleen-instellingsnavraag nie. Bevestig dat die vereiste inhoud daarna beskikbaar is. 'n Klein wyser wat in 'n gedeeltelike werkkopie oorbly, is nie die groot lêer nie, en 'n vroeëre suksesvolle Git-opdrag kan nie bewys dat die LFS-oordrag voltooi is nie.

Verwante artikels