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

नमूना endpoint बदल्नुहोस्। सार्वजनिक प्रोक्सी मान्य हुने सार्वजनिक HTTPS सबमोड्युलका लागि HTTP प्रोक्सी सूची बाट ठेगाना लिनुहोस्। यसले SSH URL लाई HTTPS बनाउँदैन; मार्ग अनपेक्षित भए URL-विशेष सेटिङ पनि जाँच्नुहोस्।

दर्ता गरिएको URL बदलिँदा

Git ले सुरुवात गर्दा सबमोड्युल कन्फिगरेसन स्थानीय रूपमा दर्ता गर्छ। प्रोक्सीलाई दोष दिनुअघि वर्तमान घोषणालाई स्थानीय मानसँग तुलना गर्नुहोस्। sync ले परियोजना घोषणाबाट URL अद्यावधिक गर्छ; यो आफैं नेटवर्क प्रोक्सी सेटिङ होइन।

नेस्टेड त्रुटिमा त्रुटिले देखाएको ठ्याक्कै सबमोड्युल पथ र remote लेख्नुहोस्। रिकर्सिभ कार्यले धेरै होस्ट सम्पर्क गर्न सक्छ; भित्री होस्टलाई प्रत्यक्ष जडान अपवाद र सार्वजनिक होस्टलाई प्रोक्सी चाहिन सक्छ।

ट्रान्सपोर्ट त्रुटि र रिपोजिटरी त्रुटि अलग राख्नुहोस्। उपलब्ध नभएको commit, अस्वीकृत पहुँच र प्रोक्सी जडान असफलता एउटै ‘submodule update failed’ परिणामका फरक कारण हुन्।