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

નમૂનાનું એન્ડપોઇન્ટ બદલો. જાહેર પ્રોક્સી માન્ય હોય તેવા માર્ગ પરના જાહેર HTTPS સબમોડ્યુલ માટે HTTP પ્રોક્સી સૂચિ સંભવિત સરનામાં આપે છે. આ SSH સબમોડ્યુલ URLને HTTPSમાં બદલતું નથી; પસંદ થયેલો માર્ગ અનપેક્ષિત હોય તો વધુ ચોક્કસ URL આધારિત ગોઠવણી પણ તપાસવી જોઈએ.

નોંધાયેલો URL બદલાયો હોય ત્યારે

Git આરંભ વખતે સબમોડ્યુલની ગોઠવણી સ્થાનિક રીતે નોંધે છે. પ્રોજેક્ટમાં સબમોડ્યુલનો URL બદલાયો હોય તો પ્રોક્સી બંધ છે એમ નક્કી કરતાં પહેલાં હાલની જાહેરાતને સ્થાનિક રીતે નોંધાયેલા મૂલ્ય સાથે સરખાવો. દસ્તાવેજિત sync ક્રિયા પ્રોજેક્ટની જાહેરાતમાંથી નોંધાયેલા URL સુધારે છે; તે પોતે નેટવર્ક પ્રોક્સી સેટિંગ નથી.

નેસ્ટેડ નિષ્ફળતાઓ માટે ભૂલમાં આપેલો ચોક્કસ સબમોડ્યુલ પાથ અને રિમોટ નોંધો. રિકર્સિવ ક્રિયા અનેક હોસ્ટનો સંપર્ક કરી શકે; જાહેર હોસ્ટ પ્રોક્સી વાપરે ત્યારે આંતરિક હોસ્ટને સીધા જોડાણનો અપવાદ જોઈએ શકે.

ટ્રાન્સપોર્ટની ભૂલોને રિપોઝિટરીની ભૂલોથી અલગ રાખો. ઉપલબ્ધ ન હોય એવો commit, રિપોઝિટરીએ નકારેલો પ્રવેશ અને પ્રોક્સી સાથે નિષ્ફળ જોડાણ—એક જ સામાન્ય ‘submodule update failed’ પરિણામનાં જુદા કારણો છે.