Proxyrouting for Git-submoduler

En vellykket kloning af hovedrepositoryet tester ikke dets submoduler. Et submodul er et andet Git-repository, muligvis på en anden vært og med en anden transport.

Begynd med at læse de erklærede URL’er:

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

Et overordnet repository hentet via HTTPS kan indeholde et submodul med git@host:. En HTTP-proxyindstilling konfigurerer ikke den SSH-forbindelse. Relative submodul-URL’er skal også opløses i forhold til superprojektets relevante remote, ikke en webadresse gættet ud fra projektnavnet.

Repositorylokale indstillinger har et afgrænset område

En lokal http.proxy-post tilhører det repository, hvis konfigurationsfil indeholder den. Antag ikke, at en undersøgelse af det overordnede repository afslører alle gældende indstillinger i et initialiseret underrepository.

For midlertidigt at overstyre HTTPS-proxyen under en rekursiv opdatering kan du give Git-kommandolinjekonfiguration til det pågældende kald:

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

Udskift eksempelendepunktet. For offentlige HTTPS-submoduler på en rute, hvor offentlige proxyer er tilladt, giver HTTP-proxylisten mulige adresser. Dette konverterer ikke SSH-submodul-URL’er til HTTPS, og mere specifik URL-baseret konfiguration bør stadig undersøges, hvis den valgte rute overrasker.

Når den registrerede URL er ændret

Git registrerer submodulkonfiguration lokalt under initialisering. Hvis projektets submodul-URL er ændret, så sammenlign den aktuelle erklæring med den lokalt registrerede værdi, før du konkluderer, at proxyen er død. Den dokumenterede sync-handling opdaterer registrerede URL’er fra projektets erklæring; den er ikke selv en netværksproxyindstilling.

Ved indlejrede fejl skal du notere den præcise submodulsti og den remote, der nævnes i fejlen. En rekursiv handling kan kontakte flere værter; en intern vært kan kræve en direkte undtagelse, mens en offentlig vært bruger proxyen.

Hold transportfejl adskilt fra repositoryfejl. En utilgængelig commit, adgang nægtet af repositoryet og en mislykket proxyforbindelse er forskellige årsager til samme overordnede resultat: ‘submodule update failed’.