Git Clone funcționează prin proxy, dar Git LFS eșuează

Urmărește separat metadatele și descărcările de obiecte Git LFS față de clonarea Git, înainte de a modifica un proxy care altfel funcționează.

O clonare poate termina transferul obiectelor Git în timp ce conținutul LFS lipsește încă. Git stochează fișiere indicator; clientul LFS face cereri separate pentru obiectele mari.

În copia de lucru afectată, cu Git LFS instalat, inspectează endpointul și ultima eroare:

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

Examinează rezultatul local; URL-urile depozitului și jurnalele pot expune informații de identificare sau de autentificare. Identifică primul pas eșuat:

  1. Contactarea API-ului LFS.
  2. Obținerea acțiunii de descărcare din Batch API.
  3. Accesarea URL-ului de descărcare al acelei acțiuni, care poate folosi un host de stocare a obiectelor diferit și antete furnizate.
  4. Transferul corpului obiectului.

Verifică atât suprascrierile endpointului LFS din depozit, cât și URL-ul real. LFS are propria implementare HTTP, propria configurație și propriul mediu proxy moștenit. Pentru Git LFS 3.7.0, urmează ordinea de selecție a proxy-ului pentru URL-ul real al cererii. Atingerea hostului HTTPS obișnuit Git nu acoperă fiecare rută ulterioară către obiecte. O eroare de autentificare la hostul de obiecte este, de asemenea, distinctă de proxy 407.

Când intenționezi descărcările, un fetch separat într-un depozit controlat poate releva eroarea fără o altă clonare:

git -C project lfs fetch

Acesta transferă obiecte; nu este o interogare de setări doar pentru citire. Confirmă după aceea că conținutul necesar este disponibil. Un indicator mic rămas într-o copie de lucru parțială nu este fișierul mare, iar o comandă Git reușită anterior nu poate stabili că transferul LFS s-a încheiat.

Articole similare