Úspešné klonovanie hlavného repozitára netestuje jeho podmoduly. Podmodul je iný repozitár Git, možno na inom hostiteľovi a možno používa iný transport.

Začnite prečítaním deklarovaných URL:

git -C project config --file .gitmodules --get-regexp '^submodule\..*\.url$'
git -C project submodule status --recursive

Rodičovský repozitár stiahnutý cez HTTPS môže obsahovať podmodul používajúci git@host:. Nastavenie HTTP proxy nekonfiguruje toto SSH spojenie. Relatívne URL podmodulov treba vyriešiť voči správnemu remote superprojektu, nie voči ľubovoľnej webovej adrese odhadnutej podľa názvu projektu.

Lokálne nastavenia repozitára majú vlastný rozsah

Lokálny záznam http.proxy patrí repozitáru, ktorého konfiguračný súbor ho obsahuje. Kontrola iba rodiča neukáže všetky efektívne nastavenia v inicializovanom podriadenom repozitári.

Pri dočasnom prepísaní HTTPS proxy počas rekurzívnej aktualizácie môžete konfiguráciu Git z príkazového riadka pridať k danému volaniu:

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

Nahraďte ukážkový endpoint. Pre verejné HTTPS podmoduly na trase, ktorá povoľuje verejné proxy, zoznam HTTP proxy ponúka kandidátne adresy. Tým sa SSH URL podmodulov nezmenia na HTTPS; ak je trasa prekvapivá, skontrolujte aj špecifickejšiu konfiguráciu URL.

Keď sa zaznamenané URL zmenilo

Git registruje konfiguráciu podmodulu lokálne počas inicializácie. Ak sa URL zmenilo, porovnajte aktuálnu deklaráciu s lokálnou hodnotou pred označením proxy za nefunkčné. Synchronizácia aktualizuje URL z deklarácie projektu; sama nie je sieťovým proxy nastavením.

Pri vnorených zlyhaniach si poznačte presnú cestu podmodulu a remote z chyby. Rekurzívna operácia môže kontaktovať viac hostiteľov; interný môže vyžadovať priamu výnimku, zatiaľ čo verejný používa proxy.

Chyby transportu oddeľte od chýb repozitára. Nedostupný commit, odmietnutý prístup a neúspešné spojenie s proxy sú rôzne dôvody rovnakého výsledku.

Súvisiace články