Kloniranje Git deluje prek proxyja, vendar Git LFS ne uspe

Spremljajte metapodatke in prenašanje objektov Git LFS ločeno od kloniranja Git, preden spremenite sicer delujoči proxy.

Kloniranje lahko konča prenos objektov Git, medtem ko vsebina LFS še vedno manjka. Git shranjuje kazalne datoteke; odjemalec LFS pošilja ločene zahteve za velike objekte.

V prizadeti delovni kopiji z nameščenim Git LFS preglejte njegov endpoint in zadnjo napako:

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

Izhod pregledajte lokalno; URL-ji repozitorija in dnevniki lahko razkrijejo identifikacijske ali overitvene podatke. Ugotovite prvo stopnjo, ki ni uspela:

  1. Vzpostavljanje stika z API-jem LFS.
  2. Pridobitev dejanja za prenos iz Batch API-ja.
  3. Doseganje URL-ja za prenos tega dejanja, ki lahko uporablja drugega gostitelja objektne shrambe in priložene glave.
  4. Prenos telesa objekta.

Preverite tudi prepise endpointa LFS v repozitoriju in dejanski URL. LFS ima svojo izvedbo HTTP, konfiguracijo in podedovano proxy okolje. Pri Git LFS 3.7.0 upoštevajte njegov vrstni red izbire proxyja za dejanski URL zahteve. Doseganje običajnega gostitelja Git HTTPS ne preizkusi vseh poznejših poti objektov. Napaka overitve na gostitelju objektov se prav tako razlikuje od proxy 407.

Ko prenose nameravate, lahko ločen fetch v nadzorovanem repozitoriju razkrije napako brez novega kloniranja:

git -C project lfs fetch

To prenaša objekte; ni poizvedba nastavitev samo za branje. Nato potrdite, da je zahtevana vsebina na voljo. Majhen kazalec, ki ostane v delni delovni kopiji, ni velika datoteka, in prej uspešen ukaz Git ne more potrditi, da se je prenos LFS končal.

Sorodni članki