Git ենթամոդուլների պրոքսի երթուղի
Երբ հիմնական Git պահոցը պրոքսիով աշխատում է, իսկ ենթապահոցները՝ ոչ, ստուգեք URL-ները, փոխանցման տեսակները և պահոցների կարգավորումները։
Հիմնական պահոցի հաջող կլոնավորումը չի ստուգում ենթամոդուլները։ Ենթամոդուլը մեկ այլ 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-ը սկզբնավորման ժամանակ ենթամոդուլի կարգավորումը տեղային է գրանցում։ Նոր հայտարարությունը համեմատեք տեղային արժեքի հետ՝ մինչև պրոքսիի վրա մեղքը դնելը։ sync գործողությունը թարմացնում է գրանցված URL-ները նախագծի հայտարարությունից, բայց ինքն ցանցային պրոքսի չէ։
Ներդրված սխալի դեպքում գրանցեք ճշգրիտ ուղին և remote-ը։ Ռեկուրսիան կարող է կապվել մի քանի հոսթի հետ․ ներքինին կարող է պետք լինել ուղղակի բացառություն, հանրայինը՝ պրոքսի։
Տարանջատեք փոխանցման և պահոցի սխալները։ Չգտնված commit-ը, մերժված հասանելիությունը և պրոքսի կապի ձախողումը «submodule update failed»-ի տարբեր պատճառներ են։