Git clone inafanya kazi kupitia proksi, lakini Git LFS inashindwa

Fuatilia metadata ya Git LFS na upakuaji wa vitu kando na clone ya Git kabla ya kubadilisha proksi inayofanya kazi kwa kawaida.

Clone inaweza kumaliza kuhamisha vitu vya Git wakati maudhui yake ya LFS bado hayapo. Git huhifadhi faili elekezi; mteja wa LFS hufanya maombi tofauti kwa vitu vikubwa.

Katika checkout iliyoathirika yenye Git LFS imesakinishwa, chunguza sehemu yake ya mwisho na hitilafu ya mwisho:

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

Kagua matokeo kwa ndani; URL za hazina na kumbukumbu zinaweza kufichua taarifa za utambulisho au uthibitishaji. Tambua hatua ya kwanza iliyoshindwa:

  1. Kuwasiliana na API ya LFS.
  2. Kupata kitendo cha upakuaji cha Batch API.
  3. Kufikia URL ya upakuaji ya kitendo hicho, ambayo inaweza kutumia host tofauti ya hifadhi ya vitu na vichwa vilivyotolewa.
  4. Kuhamisha mwili wa kitu.

Angalia mabadiliko ya sehemu ya mwisho ya LFS ya hazina pamoja na URL halisi. LFS ina utekelezaji wake wa HTTP, usanidi na mazingira ya proksi yaliyorithiwa. Kwa Git LFS 3.7.0, fuata mpangilio wake wa kuchagua proksi kwa URL halisi ya ombi. Kufikia host ya kawaida ya Git HTTPS hakutumii kila njia ya baadaye ya vitu. Hitilafu ya uthibitishaji ya host ya vitu pia ni tofauti na proxy 407.

Unapokusudia upakuaji, fetch tofauti katika hazina inayodhibitiwa inaweza kufichua hitilafu bila clone nyingine:

git -C project lfs fetch

Hii huhamisha vitu; si swali la mipangilio la kusoma tu. Thibitisha kuwa maudhui yanayohitajika yanapatikana baadaye. Kielekezi kidogo kinachobaki katika checkout isiyokamilika si faili kubwa, na amri ya Git iliyofanikiwa awali haiwezi kuthibitisha kuwa uhamishaji wa LFS ulikamilika.

Makala zinazohusiana