Proxy-ruting for Git-undermodular

Ei vellukka kloning av hovudarkivet testar ikkje undermodulane. Ein undermodul er eit anna Git-arkiv, kanskje på ein annan vert og med ein annan transport.

Start med å lese dei deklarerte URL-ane:

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

Eit foreldrearkiv henta over HTTPS kan innehalde ein undermodul som brukar git@host:. Ei HTTP-proxyinnstilling konfigurerer ikkje den SSH-sambindinga. Relative URL-ar må løysast mot rett remote for superprosjektet, ikkje mot ei nettadresse du gjetta ut frå prosjektnamnet.

Lokale innstillingar har eit verkeområde

Ei lokal http.proxy-oppføring høyrer til arkivet som har henne i konfigurasjonsfila. Å sjå på forelderen åleine viser ikkje alle aktive innstillingar i eit initialisert barn.

For mellombels HTTPS-proxy under ei rekursiv oppdatering kan du gi Git-konfigurasjon på kommandolinja til dette kallet:

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

Byt ut eksempel-endepunktet. For offentlege HTTPS-undermodular på ei rute som tillèt offentlege proxyar, gir HTTP-proxylista moglege adresser. Dette gjer ikkje SSH-URL-ar om til HTTPS; kontroller også meir spesifikk URL-konfigurasjon dersom ruta er uventa.

Når den registrerte URL-en er endra

Git registrerer undermoduloppsettet lokalt under initialisering. Samanlikn gjeldande deklarasjon med den lokale verdien før du meiner at proxyen er øydelagd. Den dokumenterte sync-operasjonen oppdaterer registrerte URL-ar frå prosjektdeklarasjonen; ho er ikkje sjølv ei nettverksproxyinnstilling.

Ved nøsta feil skal du notere nøyaktig undermodulsti og remote frå feilen. Ei rekursiv handling kan kontakte fleire vertar; ein intern vert kan trenge direkte unntak medan ein offentleg vert brukar proxyen.

Hald transportfeil frå arkivfeil. Ein utilgjengeleg commit, nekta tilgang og mislukka proxykopling er ulike grunnar til same overordna resultat «submodule update failed».