Uspešno kloniranje glavnega repozitorija ne preizkusi njegovih podmodulov. Podmodul je drug Gitov repozitorij, morda na drugem gostitelju in morda uporablja drug prenos.

Začnite z branjem deklariranih URL-jev:

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

Starševski repozitorij, pridobljen prek HTTPS, lahko vsebuje podmodul, ki uporablja git@host:. Nastavitev HTTP-proxyja ne konfigurira te povezave SSH. Relativne URL-je podmodulov razrešite glede na ustrezen remote superprojekta, ne na poljuben spletni naslov, ki ste ga sklepali iz imena projekta.

Lokalne nastavitve repozitorija imajo svoj obseg

Lokalni vnos http.proxy pripada repozitoriju, katerega konfiguracijska datoteka ga vsebuje. Pregled samo starša ne pokaže vseh učinkovitih nastavitev v inicializiranem otroškem repozitoriju.

Za začasno preglasitev HTTPS-proxyja med rekurzivno posodobitvijo lahko konfiguracijo Gita iz ukazne vrstice podate temu klicu:

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

Zamenjajte primer končne točke. Za javne HTTPS-podmodule na poti, ki dovoljuje javne proxyje, seznam HTTP-proxyjev ponuja mogoče naslove. To ne pretvori SSH-URL-jev v HTTPS; če je izbrana pot presenetljiva, preverite tudi konfiguracijo URL.

Ko se zabeleženi URL spremeni

Git med inicializacijo lokalno registrira konfiguracijo podmodula. Če se URL spremeni, primerjajte trenutno deklaracijo z lokalno vrednostjo, preden odločite, da proxy ne deluje. Sinhronizacija posodobi registrirane URL-je iz deklaracije projekta; sama ni omrežna nastavitev proxyja.

Pri ugnezdenih napakah si zabeležite natančno pot podmodula in remote iz napake. Rekurzivna operacija lahko kontaktira več gostiteljev; notranji lahko zahteva neposredno izjemo, javni pa uporablja proxy.

Napake prenosa ločite od napak repozitorija. Nedostopen commit, zavrnjen dostop in neuspešna povezava s proxyjem so različni razlogi istega splošnega rezultata.

Sorodni članki