git clone प्रॉक्सीमधून चालतो, पण Git LFS अयशस्वी होते
आधीच काम करणारी प्रॉक्सी बदलण्यापूर्वी Git LFS चे मेटाडेटा आणि ऑब्जेक्ट डाउनलोड git clone पासून वेगळे तपासा.
Git ऑब्जेक्टचे हस्तांतरण पूर्ण होऊ शकते, तरीही त्याचा LFS मजकूर अजून गहाळ असू शकतो. Git पॉइंटर फाइल्स साठवतो; LFS क्लायंट मोठ्या ऑब्जेक्टसाठी स्वतंत्र विनंत्या करतो.
Git LFS स्थापित असलेल्या प्रभावित चेकआउटमध्ये, त्याचा एंडपॉइंट आणि शेवटची अयशस्वीता तपासा:
git -C project lfs env
git -C project lfs logs lastआउटपुट स्थानिक पातळीवर तपासा; रेपॉझिटरी URL आणि लॉग ओळखणारी किंवा प्रमाणीकरणाची माहिती उघड करू शकतात.
- LFS API शी संपर्क करणे.
- Batch API ची डाउनलोड क्रिया मिळवणे.
- त्या क्रियेच्या डाउनलोड URL पर्यंत पोहोचणे, जे वेगळा ऑब्जेक्ट-स्टोरेज होस्ट आणि पुरवलेली हेडर वापरू शकते.
- ऑब्जेक्टचे मुख्य भाग हस्तांतरित करणे.
रेपॉझिटरी LFS एंडपॉइंट ओव्हरराइड्स तसेच प्रत्यक्ष URL तपासा. LFS ची स्वतःची HTTP अंमलबजावणी, संरचना आणि वारशाने मिळालेले प्रॉक्सी वातावरण आहे. Git LFS 3.7.0 साठी, प्रत्यक्ष विनंती URL साठी त्याच्या प्रॉक्सी-निवड क्रमाचे पालन करा. सामान्य Git HTTPS होस्टपर्यंत पोहोचणे पुढील प्रत्येक ऑब्जेक्ट मार्गाची चाचणी करत नाही. ऑब्जेक्ट-होस्ट प्रमाणीकरण अयशस्वी होणे देखील प्रॉक्सी 407 पेक्षा वेगळे आहे.
जेव्हा तुम्हाला डाउनलोड हवे असतील, तेव्हा नियंत्रित रेपॉझिटरीमध्ये स्वतंत्र fetch आणखी एका clone शिवाय अयशस्वीता उघड करू शकते:
git -C project lfs fetchहे ऑब्जेक्ट हस्तांतरित करते; ही केवळ-वाचनीय सेटिंग्जची चौकशी नाही. त्यानंतर आवश्यक मजकूर उपलब्ध आहे का ते तपासा. अपूर्ण चेकआउटमध्ये राहिलेला लहान पॉइंटर मोठी फाइल नाही, आणि आधीच्या यशस्वी Git कमांडवरून LFS हस्तांतरण पूर्ण झाले असे सिद्ध होत नाही.