Git क्लोन प्रॉक्सी के ज़रिए काम करता है, पर Git LFS विफल होता है
अन्यथा काम कर रहे प्रॉक्सी को बदलने से पहले Git LFS मेटाडेटा और ऑब्जेक्ट डाउनलोड को Git क्लोन से अलग ट्रेस करें।
एक क्लोन 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 किसी अन्य क्लोन के बिना विफलता उजागर कर सकता है:
git -C project lfs fetchयह ऑब्जेक्ट्स स्थानांतरित करता है; यह केवल-पढ़ने वाली सेटिंग्स क्वेरी नहीं है। पुष्टि करें कि आवश्यक कंटेंट इसके बाद उपलब्ध है। आंशिक चेकआउट में बचा छोटा पॉइंटर बड़ी फ़ाइल नहीं है, और पहले की सफल Git कमांड यह सिद्ध नहीं कर सकती कि LFS स्थानांतरण पूरा हुआ।