Git apakšmoduļu maršrutēšana caur starpniekserveri

Pārbaudiet apakšmoduļu URL, transporta veidus un repozitoriju konfigurāciju, ja galvenais Git repozitorijs darbojas caur starpniekserveri, bet pakārtotie ne.

Galvenā repozitorija veiksmīga klonēšana nepārbauda tā apakšmoduļus. Apakšmodulis ir cits Git repozitorijs, iespējams, citā resursdatorā un ar citu transportu.

Sāciet ar deklarēto URL lasīšanu:

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

Vecākrepozitorijā, kas iegūts caur HTTPS, var būt apakšmodulis ar git@host:. HTTP starpniekservera iestatījums nekonfigurē šo SSH savienojumu. Relatīvie apakšmoduļu URL arī jāatrisina attiecībā pret virsprojekta atbilstošo attālo repozitoriju, nevis tīmekļa adresi, ko pieņēmāt no projekta nosaukuma.

Repozitorija vietējiem iestatījumiem ir tvērums

Vietējais http.proxy ieraksts pieder repozitorijam, kura konfigurācijas failā tas atrodas. Nepieņemiet, ka tikai vecākrepozitorija apskate atklāj visus spēkā esošos iestatījumus inicializētā bērnrepozitorijā.

Lai rekursīvas atjaunināšanas laikā īslaicīgi pārrakstītu HTTPS starpniekserveri, šim izsaukumam var nodot Git komandrindas konfigurāciju:

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

Aizstājiet parauga galapunktu. Publiskiem HTTPS apakšmoduļiem maršrutā, kur atļauti publiski starpniekserveri, HTTP starpniekserveru saraksts piedāvā adreses. Tas nepārveido SSH URL par HTTPS; ja izvēlētais maršruts pārsteidz, pārbaudiet arī specifiskāku URL konfigurāciju.

Kad reģistrētais URL ir mainījies

Git inicializēšanas laikā reģistrē apakšmoduļa konfigurāciju vietēji. Ja projekta apakšmoduļa URL ir mainījies, salīdziniet pašreizējo deklarāciju ar vietēji reģistrēto vērtību, pirms secināt, ka starpniekserveris nedarbojas. Dokumentētā sync darbība atjaunina reģistrētos URL no projekta deklarācijas; tā pati nav tīkla starpniekservera iestatījums.

Ligzdotu kļūmju gadījumā pierakstiet precīzu apakšmoduļa ceļu un kļūdā nosaukto attālo repozitoriju. Rekursīva darbība var sazināties ar vairākiem resursdatoriem; iekšējam var būt vajadzīgs tieša savienojuma izņēmums, kamēr publisks izmanto starpniekserveri.

Nošķiriet transporta kļūdas no repozitorija kļūdām. Nepieejams commit, repozitorija liegta piekļuve un neizdevies savienojums ar starpniekserveri ir dažādi iemesli tam pašam vispārīgajam rezultātam „submodule update failed“.

Saistītie raksti