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 हे सुपरप्रोजेक्टच्या योग्य remoteच्या संदर्भात सोडवा, प्रोजेक्टच्या नावावरून गृहित धरलेल्या वेब पत्त्याच्या संदर्भात नाही.

रिपॉझिटरी-स्थानिक सेटिंगची व्याप्ती असते

स्थानिक http.proxy नोंद ज्या रिपॉझिटरीच्या कॉन्फिगरेशन फाइलमध्ये आहे तिची असते. फक्त मूळ भंडार पाहून आरंभ केलेल्या उपभंडारातील सर्व प्रभावी सेटिंग कळतील असे समजू नका.

रिकर्सिव्ह अपडेटसाठी तात्पुरती HTTPS प्रॉक्सी द्यायची असल्यास त्या कॉलला Git कमांड-लाइन कॉन्फिगरेशन देता येते:

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

उदाहरणातील एंडपॉइंट बदला. सार्वजनिक प्रॉक्सी मान्य असलेल्या मार्गावरील सार्वजनिक HTTPS सबमॉड्यूलसाठी HTTP प्रॉक्सी यादी संभाव्य पत्ते देते. हे SSH URLना HTTPSमध्ये बदलत नाही; अनपेक्षित मार्गासाठी अधिक विशिष्ट URL-आधारित सेटिंगही तपासा.

नोंदवलेला URL बदलल्यावर

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

नेस्टेड अपयशात त्रुटीत दिलेला अचूक पथ आणि remote नोंदवा. रिकर्सिव्ह क्रिया अनेक होस्टशी संपर्क करू शकते; सार्वजनिक होस्ट प्रॉक्सी वापरताना अंतर्गत होस्टला थेट जोडणीचा अपवाद लागू शकतो.

ट्रान्सपोर्टच्या त्रुटी रिपॉझिटरीच्या त्रुटींपासून वेगळ्या ठेवा. अनुपलब्ध commit, नाकारलेला प्रवेश आणि अपयशी प्रॉक्सी जोडणी ही एकाच ‘submodule update failed’ निकालाची वेगळी कारणे आहेत.