Usmjeravanje proxyja za Git podmodule

Uspješno kloniranje glavnog repozitorija ne testira njegove podmodule. Podmodul je drugi Git repozitorij, možda na drugom hostu i možda koristi drugi transport.

Počnite čitanjem deklarisanih URL-ova:

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

Roditeljski repozitorij preuzet preko HTTPS-a može sadržati podmodul koji koristi git@host:. HTTP proxy postavka ne konfiguriše tu SSH vezu. Relativne URL-ove treba razriješiti prema odgovarajućem remote-u superprojekta, a ne prema web adresi pretpostavljenoj iz imena projekta.

Lokalne postavke repozitorija imaju svoj opseg

Lokalni unos http.proxy pripada repozitoriju čija ga konfiguracijska datoteka sadrži. Pregled samo roditelja ne pokazuje sve efektivne postavke u inicijaliziranom podređenom repozitoriju.

Za privremeno preusmjeravanje HTTPS proxyja tokom rekurzivnog ažuriranja, Git konfiguraciju iz komandne linije proslijedite tom pozivu:

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

Zamijenite primjer krajnje tačke. Za javne HTTPS podmodule na ruti koja dozvoljava javne proxyje, HTTP lista proxyja nudi moguće adrese. To ne pretvara SSH URL-ove u HTTPS; provjerite i specifičniju konfiguraciju ako je ruta neočekivana.

Kada se registrovani URL promijeni

Git lokalno registruje konfiguraciju podmodula tokom inicijalizacije. Ako se URL promijenio, uporedite trenutnu deklaraciju s lokalnom vrijednošću prije zaključka da proxy ne radi. Sinhronizacija ažurira URL-ove iz deklaracije projekta; nije sama mrežna proxy postavka.

Kod ugniježđenih grešaka zabilježite tačnu putanju podmodula i remote iz greške. Rekurzivna operacija može kontaktirati više hostova; internom može trebati direktni izuzetak, a javni koristi proxy.

Greške transporta odvojite od grešaka repozitorija. Nedostupan commit, uskraćen pristup i neuspjela veza s proxyjem različiti su razlozi istog rezultata.