Git clone funksionon përmes proxy-t, por Git LFS dështon

Gjurmo metadatat dhe shkarkimet e objekteve të Git LFS veçmas nga clone-i i Git përpara se të ndryshosh një proxy që funksionon normalisht.

Një clone mund të përfundojë transferimin e objekteve Git, ndërsa përmbajtja e tij LFS ende mungon. Git ruan skedarë tregues; klienti LFS bën kërkesa të veçanta për objektet e mëdha.

Në checkout-in e prekur me Git LFS të instaluar, shqyrto pikën fundore dhe dështimin e fundit të tij:

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

Shqyrto daljen lokalisht; URL-të dhe regjistrat e depos mund të zbulojnë informacione identifikuese ose vërtetimi. Identifiko fazën e parë që dështoi:

  1. Kontaktimi i API-së LFS.
  2. Marrja e veprimit të shkarkimit të Batch API.
  3. Arritja e URL-së së shkarkimit të atij veprimi, e cila mund të përdorë një host tjetër të ruajtjes së objekteve dhe header-at e dhënë.
  4. Transferimi i trupit të objektit.

Kontrollo anashkalimet e pikës fundore LFS të depos si dhe URL-në aktuale. LFS ka implementimin e vet HTTP, konfigurimin dhe mjedisin e proxy-t të trashëguar. Për Git LFS 3.7.0, ndiq rendin e zgjedhjes së proxy-t për URL-në aktuale të kërkesës. Arritja e hostit të zakonshëm Git HTTPS nuk provon çdo rrugë të mëvonshme të objekteve. Një dështim vërtetimi i hostit të objekteve është gjithashtu i ndryshëm nga proxy 407.

Kur synon shkarkimet, një fetch i veçantë në një depo të kontrolluar mund ta zbulojë dështimin pa një clone tjetër:

git -C project lfs fetch

Kjo transferon objekte; nuk është një pyetje e vetme e cilësimeve vetëm për lexim. Konfirmo se përmbajtja e kërkuar është e disponueshme më pas. Një tregues i vogël që mbetet në një checkout të pjesshëm nuk është skedari i madh, dhe një komandë e mëparshme e suksesshme Git nuk mund të vërtetojë se transferimi LFS përfundoi.

Artikuj të ngjashëm