git clone töötab puhverserveri kaudu, kuid Git LFS ebaõnnestub

Jälgi Git LFS-i metaandmeid ja objektide allalaadimisi git clone'ist eraldi, enne kui muudad muidu toimivat puhverserverit.

Kloonimine võib Git-objektide ülekandmise lõpetada, samal ajal kui selle LFS-sisu on endiselt puudu. Git hoiab viitfaile; LFS-klients teeb suurte objektide jaoks eraldi päringuid.

Mõjutatud töökopeerimises (checkout), kus Git LFS on paigaldatud, kontrolli selle lõpp-punkti ja viimast ebaõnnestumist:

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

Vaata väljundit kohapeal; hoidla URL-id ja logid võivad paljastada identifitseerivat või autentimisteavet. Tee kindlaks esimene ebaõnnestunud etapp:

  1. LFS-i API-ga ühenduse võtmine.
  2. Batch API allalaadimistoimingu hankimine.
  3. Selle toimingu allalaadimis-URL-ile jõudmine, mis võib kasutada teist objektihoidla hosti ja antud päiseid.
  4. Objekti keha ülekandmine.

Kontrolli hoidla LFS-i lõpp-punkti alistusi ja ka tegelikku URL-i. LFS-il on oma HTTP-teostus, konfiguratsioon ja päritud puhverserveri keskkond. Git LFS 3.7.0 puhul järgi selle puhverserveri valiku järjekorda tegeliku päringu URL-i jaoks. Git-i tavalise HTTPS-hosti külastamine ei harjuta kõiki hilisemaid objektimarsruute. Autentimise ebaõnnestumine objektihostis erineb ka puhverserveri 407-st.

Kui kavatsed allalaadimisi teha, võib eraldi fetch kontrollitud hoidlas paljastada ebaõnnestumise ilma uue kloonita:

git -C project lfs fetch

See edastab objekte; see ei ole ainult lugemiseks mõeldud seadete päring. Kinnita pärast seda, et vajalik sisu on saadaval. Osalisse töökopeerimisse jäänud väike viit ei ole suur fail, ja varem õnnestunud Git-käsk ei saa tõestada, et LFS-i ülekanne lõppes.

Seotud artiklid