„Git“ submodulių tarpinio serverio maršrutai

Sėkmingas pagrindinės saugyklos klonavimas nepatikrina submodulių. Submodulis yra kita „Git“ saugykla, galbūt kitame pagrindiniame kompiuteryje ir naudojanti kitą perdavimą.

Pradėkite perskaitydami deklaruotus URL:

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

Per HTTPS gautoje tėvinėje saugykloje gali būti submodulis su git@host:. HTTP tarpinio serverio nustatymas nekonfigūruoja šio SSH ryšio. Santykinius submodulių URL taip pat spręskite pagal tinkamą superprojekto remote, o ne pagal iš projekto pavadinimo numanytą žiniatinklio adresą.

Vietinių saugyklos nustatymų aprėptis

Vietinis http.proxy įrašas priklauso saugyklai, kurios konfigūracijos faile jis yra. Vien tėvinės saugyklos patikra neparodo visų pradėtoje vaikinėje saugykloje veikiančių nustatymų.

Laikiną HTTPS tarpinį serverį rekursiniam naujinimui perduokite Git komandinės eilutės konfigūracija:

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

Pakeiskite pavyzdinį galinį tašką. Viešiems HTTPS submoduliams naudokite HTTP tarpinių serverių sąrašo adresus. Tai nekeičia SSH URL į HTTPS; netikėto maršruto atveju patikrinkite konkretesnę URL konfigūraciją.

Kai įrašytas URL pasikeitė

Git inicijuojant vietoje registruoja submodulio konfigūraciją. Prieš kaltindami tarpinį serverį palyginkite dabartinę deklaraciją su vietine reikšme. Dokumentuota sync operacija atnaujina URL iš projekto deklaracijos, bet pati nėra tinklo tarpinio serverio nustatymas.

Įdėtoje klaidoje užrašykite tikslų submodulio kelią ir remote. Rekursinė operacija gali pasiekti kelis pagrindinius kompiuterius; vidiniam gali reikėti tiesioginio ryšio išimties, viešam – tarpinio serverio.

Atskirkite perdavimo ir saugyklos klaidas. Nerastas commit, atmesta prieiga ir nepavykęs ryšys su tarpiniu serveriu yra skirtingos „submodule update failed“ priežastys.