Կլոնը կարող է ավարտել Git օբյեկտների փոխանցումը, մինչ LFS-ի բովանդակությունը դեռ բացակայում է։ Git-ը պահում է ցուցիչ ֆայլեր, իսկ LFS-ի հաճախորդը մեծ օբյեկտների համար առանձին հարցումներ է կատարում։

Տուժած checkout-ում՝ տեղադրված Git LFS-ով, ստուգեք դրա endpoint-ը և վերջին ձախողումը:

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

Ելքը դիտեք տեղում. ռեպոզիտորիայի URL-ները և մատյանները կարող են բացահայտել նույնականացման կամ վավերացման տեղեկություններ։ Որոշեք առաջին ձախողված փուլը:

  1. LFS API-ի հետ կապ հաստատելը։
  2. Batch API-ի ներբեռնման գործողությունը ստանալը։
  3. Այդ գործողության ներբեռնման URL-ին հասնելը, որը կարող է օգտագործել այլ օբյեկտների պահոցի հոսթ և տրամադրված վերնագրեր։
  4. Օբյեկտի մարմնի փոխանցումը։

Ստուգեք ռեպոզիտորիայի LFS endpoint-ի վերասահմանումները, ինչպես նաև փաստացի URL-ը։ LFS-ն ունի սեփական HTTP իրականացում, կարգավորումներ և ժառանգված պրոքսի միջավայր։ Git LFS 3.7.0-ի համար փաստացի հարցման URL-ի համար հետևեք դրա պրոքսի ընտրության կարգին։ Սովորական Git HTTPS հոսթին հասնելը չի անցնում բոլոր հետագա օբյեկտների երթուղիներով։ Օբյեկտների հոսթի վավերացման ձախողումը նույնպես տարբերվում է պրոքսի 407-ից։

Երբ նախատեսում եք ներբեռնումները, վերահսկվող ռեպոզիտորիայում առանձին fetch-ը կարող է բացահայտել ձախողումը՝ առանց նոր կլոնի:

git -C project lfs fetch

Սա փոխանցում է օբյեկտներ, այն միայն կարդալու կարգավորումների հարցում չէ։ Հետո հաստատեք, որ պահանջվող բովանդակությունը հասանելի է։ Մասնակի checkout-ում մնացած փոքր ցուցիչը մեծ ֆայլը չէ, և ավելի վաղ հաջողված Git հրամանը չի կարող հաստատել, որ LFS-ի փոխանցումն ավարտվել է։

Առնչվող հոդվածներ