Proxy-Routing für Git-Submodule
Prüfen Sie Submodul-URLs, Transportarten und Repository-Konfigurationen, wenn das Hauptprojekt über einen Proxy funktioniert, seine Unterprojekte jedoch nicht.
Ein erfolgreiches Klonen des Hauptrepositorys testet dessen Submodule nicht. Ein Submodul ist ein weiteres Git-Repository, möglicherweise auf einem anderen Host und mit einem anderen Transport.
Lesen Sie zuerst die deklarierten URLs:
git -C project config --file .gitmodules --get-regexp '^submodule\..*\.url$'
git -C project submodule status --recursive
Ein über HTTPS abgerufenes übergeordnetes Repository kann ein Submodul mit git@host: enthalten. Eine HTTP-Proxy-Einstellung konfiguriert diese SSH-Verbindung nicht. Relative Submodul-URLs müssen außerdem gegen das passende Remote des Superprojekts aufgelöst werden, nicht gegen eine aus dem Projektnamen vermutete Webadresse.
Repository-lokale Einstellungen haben einen Geltungsbereich
Ein lokaler Eintrag für http.proxy gehört zu dem Repository, dessen Konfigurationsdatei ihn enthält. Gehen Sie nicht davon aus, dass eine Prüfung allein des übergeordneten Repositorys sämtliche wirksamen Einstellungen eines initialisierten Unterrepositorys zeigt.
Für eine vorübergehende HTTPS-Proxy-Vorgabe bei einem rekursiven Update können Sie diesem Aufruf Git-Konfiguration auf der Kommandozeile mitgeben:
git -C project -c http.proxy=http://203.0.113.10:8080 \
submodule update --init --recursive
Ersetzen Sie den Beispielendpunkt. Für öffentliche HTTPS-Submodule auf einem Weg, der öffentliche Proxys erlaubt, liefert die HTTP-Proxy-Liste mögliche Adressen. Dadurch werden SSH-Submodul-URLs nicht in HTTPS umgewandelt. Bei unerwartetem Routing lohnt sich auch die Prüfung spezifischerer URL-basierter Konfiguration.
Wenn sich die gespeicherte URL geändert hat
Git registriert die Submodulkonfiguration bei der Initialisierung lokal. Hat sich die Submodul-URL im Projekt geändert, vergleichen Sie die aktuelle Deklaration mit dem lokal registrierten Wert, bevor Sie den Proxy für ausgefallen halten. Die dokumentierte sync-Operation aktualisiert registrierte URLs aus der Projektdeklaration; sie ist selbst keine Netzwerkproxy-Einstellung.
Notieren Sie bei verschachtelten Fehlern den genauen Submodulpfad und das in der Meldung genannte Remote. Ein rekursiver Vorgang kann mehrere Hosts kontaktieren. Ein interner Host benötigt womöglich eine Ausnahme für direkten Zugriff, während ein öffentlicher den Proxy verwendet.
Trennen Sie Transportfehler von Repository-Fehlern. Ein nicht verfügbarer Commit, vom Repository verweigerter Zugriff und eine gescheiterte Proxyverbindung sind unterschiedliche Ursachen desselben allgemeinen Ergebnisses „submodule update failed“.