Klon repositori utama yang berhasil tidak menguji submodulnya. Submodul adalah repositori Git lain, mungkin di host lain dan memakai transportasi lain.

Mulai dengan membaca URL yang dideklarasikan:

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

Repositori induk yang diambil lewat HTTPS dapat berisi submodul yang memakai git@host:. Pengaturan proxy HTTP tidak mengatur koneksi SSH itu. URL relatif submodul harus di-resolve terhadap remote superproject yang tepat, bukan alamat web yang ditebak dari nama proyek.

Pengaturan lokal repositori memiliki cakupan

Entri http.proxy lokal berlaku untuk repositori yang file konfigurasinya memuatnya. Jangan menganggap pemeriksaan induk saja menampilkan semua pengaturan efektif di repositori anak yang sudah diinisialisasi.

Untuk override proxy HTTPS sementara saat pembaruan rekursif, berikan konfigurasi baris perintah Git pada pemanggilan tersebut:

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

Ganti endpoint contoh. Untuk submodul HTTPS publik pada rute yang mengizinkan proxy publik, daftar proxy HTTP menyediakan alamat kandidat. Ini tidak mengubah URL SSH menjadi HTTPS; periksa konfigurasi berbasis URL yang lebih spesifik jika rutenya mengejutkan.

Saat URL yang tercatat berubah

Git mendaftarkan konfigurasi submodul secara lokal saat inisialisasi. Jika URL berubah, bandingkan deklarasi kini dengan nilai lokal sebelum menyalahkan proxy. Operasi sync memperbarui URL dari deklarasi proyek; itu sendiri bukan setelan proxy jaringan.

Pada kegagalan bertingkat, catat jalur submodul dan remote yang disebutkan. Operasi rekursif dapat menghubungi banyak host; host internal mungkin perlu pengecualian langsung sementara host publik memakai proxy.

Pisahkan kesalahan transportasi dari kesalahan repositori. Commit yang tidak tersedia, akses ditolak, dan koneksi proxy gagal adalah alasan berbeda untuk hasil umum ‘submodule update failed’.

Artikel terkait