Proxyútvonalak Git-almodulokhoz

Ellenőrizze az almodulok URL-jeit, a transzportokat és a tárházbeállításokat, amikor a fő Git-tárház proxyn át működik, de az almodulok nem.

A fő tárház sikeres klónozása nem teszteli az almodulokat. Az almodul egy másik Git-tárház, másik gépen és más transzporttal is lehet.

Olvassa el először a deklarált URL-eket:

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

A HTTPS-en lekért szülőtárház git@host: használó almodult tartalmazhat. A HTTP-proxy beállítása nem konfigurálja ezt az SSH-kapcsolatot. A relatív URL-eket a szuperprojekt megfelelő remote-jához, ne a projekt nevéből kitalált webcímhez viszonyítsa.

A tárház helyi beállításainak hatóköre van

A helyi http.proxy bejegyzés ahhoz a tárházhoz tartozik, amelynek konfigurációs fájlja tartalmazza. A szülő vizsgálata nem fedi fel egy inicializált gyermek minden érvényes beállítását.

Rekurzív frissítéshez ideiglenes HTTPS-proxyt a Git parancssori konfigurációjával adhat ehhez a híváshoz:

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

Cserélje ki a példavégpontot. Nyilvános HTTPS-almodulokhoz használja a HTTP-proxylistából származó címet. Ez nem alakítja át az SSH-URL-eket HTTPS-re; meglepő útvonalnál nézze meg a konkrétabb URL-szabályt is.

Ha a rögzített URL megváltozott

A Git inicializáláskor helyben regisztrálja az almodul beállításait. Hasonlítsa össze az új deklarációt a helyi értékkel, mielőtt a proxyt hibáztatja. A dokumentált sync a projektdeklarációból frissíti a regisztrált URL-eket; önmagában nem hálózati proxybeállítás.

Beágyazott hiba esetén írja fel a pontos almodulútvonalat és a hiba remote-ját. A rekurzív művelet több gépet érinthet; a belső közvetlen kivételt, a nyilvános proxyt használhat.

Válassza külön a transzport- és tárházhibákat. Hiányzó commit, megtagadott hozzáférés és sikertelen proxykapcsolat más-más oka a „submodule update failed” eredménynek.

Kapcsolódó cikkek