Git सबमॉड्यूल के लिए प्रॉक्सी रूटिंग

मुख्य रिपॉज़िटरी का सफल क्लोन उसके सबमॉड्यूल की जाँच नहीं करता। सबमॉड्यूल एक दूसरी Git रिपॉज़िटरी है, जो दूसरे होस्ट और दूसरे ट्रांसपोर्ट पर हो सकती है।

घोषित URL पढ़कर शुरू करें:

git -C project config --file .gitmodules --get-regexp '^submodule\..*\.url$'
git -C project submodule status --recursive

HTTPS से प्राप्त पैरेंट में git@host: वाला सबमॉड्यूल हो सकता है। HTTP प्रॉक्सी सेटिंग उस SSH कनेक्शन को कॉन्फ़िगर नहीं करती। रिलेटिव URL को सुपरप्रोजेक्ट के सही रिमोट के आधार पर हल करें, प्रोजेक्ट नाम से अनुमानित वेब पते के आधार पर नहीं।

रिपॉज़िटरी-स्थानीय सेटिंग की सीमा होती है

स्थानीय http.proxy प्रविष्टि उस रिपॉज़िटरी की होती है जिसकी कॉन्फ़िगरेशन फ़ाइल उसे रखती है। केवल पैरेंट देखकर आरंभ किए गए बच्चे की सभी प्रभावी सेटिंग न मानें।

रिकर्सिव अपडेट में अस्थायी HTTPS प्रॉक्सी के लिए उसी कॉल को Git कमांड-लाइन कॉन्फ़िगरेशन दें:

git -C project -c http.proxy=http://203.0.113.10:8080 \
  submodule update --init --recursive

उदाहरण endpoint बदलें। सार्वजनिक HTTPS सबमॉड्यूल के लिए HTTP प्रॉक्सी सूची से पता लें। यह SSH URL को HTTPS नहीं बनाता; अनपेक्षित मार्ग पर अधिक विशिष्ट URL सेटिंग भी जाँचें।

जब दर्ज URL बदला हो

Git आरंभ के समय सबमॉड्यूल कॉन्फ़िगरेशन स्थानीय रूप से दर्ज करता है। URL बदलने पर प्रॉक्सी को दोष देने से पहले वर्तमान घोषणा और स्थानीय मान की तुलना करें। दस्तावेज़ित sync घोषणा से दर्ज URL अपडेट करता है; यह स्वयं नेटवर्क प्रॉक्सी सेटिंग नहीं है।

नेस्टेड विफलता में त्रुटि का सटीक पथ और remote लिखें। रिकर्सिव कार्य कई होस्ट से जुड़ सकता है; आंतरिक होस्ट को सीधा अपवाद और सार्वजनिक होस्ट को प्रॉक्सी चाहिए हो सकता है।

ट्रांसपोर्ट त्रुटि और रिपॉज़िटरी त्रुटि अलग रखें। अनुपलब्ध commit, अस्वीकृत पहुँच और प्रॉक्सी कनेक्शन विफलता एक ही ‘submodule update failed’ के अलग कारण हैं।