Git clone-ը աշխատում է պրոքսի միջով, բայց Git LFS-ը ձախողվում է
Առանձին հետևեք Git LFS-ի մետատվյալների և օբյեկտների ներբեռնմանը Git clone-ից, նախքան աշխատող պրոքսը փոխելը։
Կլոնը կարող է ավարտել Git օբյեկտների փոխանցումը, մինչ LFS-ի բովանդակությունը դեռ բացակայում է։ Git-ը պահում է ցուցիչ ֆայլեր, իսկ LFS-ի հաճախորդը մեծ օբյեկտների համար առանձին հարցումներ է կատարում։
Տուժած checkout-ում՝ տեղադրված Git LFS-ով, ստուգեք դրա endpoint-ը և վերջին ձախողումը:
git -C project lfs env
git -C project lfs logs lastԵլքը դիտեք տեղում. ռեպոզիտորիայի URL-ները և մատյանները կարող են բացահայտել նույնականացման կամ վավերացման տեղեկություններ։ Որոշեք առաջին ձախողված փուլը:
- LFS API-ի հետ կապ հաստատելը։
- Batch API-ի ներբեռնման գործողությունը ստանալը։
- Այդ գործողության ներբեռնման URL-ին հասնելը, որը կարող է օգտագործել այլ օբյեկտների պահոցի հոսթ և տրամադրված վերնագրեր։
- Օբյեկտի մարմնի փոխանցումը։
Ստուգեք ռեպոզիտորիայի LFS endpoint-ի վերասահմանումները, ինչպես նաև փաստացի URL-ը։ LFS-ն ունի սեփական HTTP իրականացում, կարգավորումներ և ժառանգված պրոքսի միջավայր։ Git LFS 3.7.0-ի համար փաստացի հարցման URL-ի համար հետևեք դրա պրոքսի ընտրության կարգին։ Սովորական Git HTTPS հոսթին հասնելը չի անցնում բոլոր հետագա օբյեկտների երթուղիներով։ Օբյեկտների հոսթի վավերացման ձախողումը նույնպես տարբերվում է պրոքսի 407-ից։
Երբ նախատեսում եք ներբեռնումները, վերահսկվող ռեպոզիտորիայում առանձին fetch-ը կարող է բացահայտել ձախողումը՝ առանց նոր կլոնի:
git -C project lfs fetchՍա փոխանցում է օբյեկտներ, այն միայն կարդալու կարգավորումների հարցում չէ։ Հետո հաստատեք, որ պահանջվող բովանդակությունը հասանելի է։ Մասնակի checkout-ում մնացած փոքր ցուցիչը մեծ ֆայլը չէ, և ավելի վաղ հաջողված Git հրամանը չի կարող հաստատել, որ LFS-ի փոխանցումն ավարտվել է։