Հիմնական պահոցի հաջող կլոնավորումը չի ստուգում ենթամոդուլները։ Ենթամոդուլը մեկ այլ 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»-ի տարբեր պատճառներ են։

Առնչվող հոդվածներ