Proxy routing para sa mga Git submodule
Suriin ang mga URL ng submodule, uri ng transport, at configuration ng repository kapag gumagana sa proxy ang pangunahing Git checkout pero hindi ang mga child repository.
Hindi sinusubok ng matagumpay na clone ng pangunahing repository ang mga submodule nito. Ang submodule ay ibang Git repository, maaaring nasa ibang host at maaaring gumagamit ng ibang transport.
Magsimula sa pagbasa ng mga idineklarang URL:
git -C project config --file .gitmodules --get-regexp '^submodule\..*\.url$'
git -C project submodule status --recursive
Maaaring may submodule ang parent repository na nakuha sa HTTPS na gumagamit ng git@host:. Hindi kino-configure ng HTTP proxy setting ang SSH connection na iyon. Dapat ding i-resolve ang relative submodule URL batay sa tamang remote ng superproject, hindi sa web address na inakala mo mula sa pangalan ng proyekto.
May saklaw ang mga setting na lokal sa repository
Ang lokal na http.proxy entry ay pag-aari ng repository na may entry sa configuration file nito. Huwag ipagpalagay na ipinapakita ng pagtingin sa parent lamang ang lahat ng effective setting sa initialized child repository.
Para sa pansamantalang HTTPS proxy override sa recursive update, maaaring ibigay ang Git command-line configuration sa invocation na iyon:
git -C project -c http.proxy=http://203.0.113.10:8080 \
submodule update --init --recursive
Palitan ang halimbawang endpoint. Para sa public HTTPS submodule sa rutang pumapayag sa public proxy, nagbibigay ang HTTP proxy list ng mga kandidatong address. Hindi nito ginagawang HTTPS ang SSH URL ng submodule; suriin din ang mas tiyak na URL configuration kapag nakakagulat ang napiling ruta.
Kapag nagbago ang nakarehistrong URL
Nirerehistro ng Git nang lokal ang configuration ng submodule habang nag-i-initialize. Kung nagbago ang URL ng submodule sa proyekto, ikumpara ang kasalukuyang declaration sa lokal na registered value bago sabihing sira ang proxy. Ina-update ng documented sync operation ang registered URL mula sa project declaration; hindi ito mismo network proxy setting.
Sa nested failure, itala ang eksaktong submodule path at remote na nasa error. Maaaring kumontak ng maraming host ang recursive operation; maaaring kailangan ng direct exception ang internal host habang gumagamit ng proxy ang public host.
Ihiwalay ang transport error sa repository error. Ang unavailable commit, pagtanggi ng repository sa access, at nabigong koneksyon sa proxy ay magkakaibang dahilan ng iisang mataas na antas na resultang “nabigo ang submodule update”