การกำหนดเส้นทางพร็อกซีสำหรับ submodule ของ Git

การ clone repository หลักสำเร็จไม่ได้ทดสอบ submodule ของมัน submodule คือ repository Git อีกแห่ง ซึ่งอาจอยู่คนละโฮสต์และใช้การรับส่งคนละแบบ

เริ่มจากอ่าน URL ที่ประกาศไว้:

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

repository แม่ที่ดึงผ่าน HTTPS อาจมี submodule ที่ใช้ git@host: การตั้งค่า HTTP proxy ไม่ได้กำหนดค่าการเชื่อมต่อ SSH นั้น URL แบบ relative ของ submodule ต้องแก้เทียบกับ remote ที่ถูกต้องของ superproject ไม่ใช่เว็บแอดเดรสที่คาดเดาจากชื่อโครงการ

การตั้งค่าเฉพาะ repository มีขอบเขตของตัวเอง

รายการ http.proxy ในเครื่องเป็นของ repository ที่มีรายการนี้อยู่ในไฟล์กำหนดค่า อย่าคิดว่าการตรวจเฉพาะ repository แม่จะแสดงค่าที่ใช้จริงทั้งหมดใน repository ลูกที่ initialize แล้ว

หากต้องการ override HTTPS proxy ชั่วคราวระหว่างการอัปเดตแบบ recursive สามารถส่งการตั้งค่า Git จากบรรทัดคำสั่งไปกับการเรียกนั้นได้:

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

แทนที่ endpoint ตัวอย่าง สำหรับ submodule HTTPS สาธารณะบนเส้นทางที่อนุญาตพร็อกซีสาธารณะ รายการ HTTP proxy มีแอดเดรสให้เลือก วิธีนี้ไม่เปลี่ยน URL SSH ของ submodule เป็น HTTPS และควรตรวจสอบการตั้งค่าเฉพาะ URL เมื่อเส้นทางที่เลือกดูผิดปกติ

เมื่อ URL ที่ลงทะเบียนไว้เปลี่ยน

Git จะลงทะเบียนการตั้งค่า submodule ไว้ในเครื่องระหว่างการ initialize หาก URL ของ submodule ในโครงการเปลี่ยน ให้เปรียบเทียบประกาศปัจจุบันกับค่าที่ลงทะเบียนไว้ก่อนสรุปว่าพร็อกซีเสีย การ sync ที่ระบุในเอกสารจะอัปเดต URL ที่ลงทะเบียนจากประกาศของโครงการ ไม่ใช่การตั้งค่า network proxy

เมื่อเกิดข้อผิดพลาดซ้อนกัน ให้จด path ของ submodule และ remote ที่ระบุในข้อผิดพลาด การทำงานแบบ recursive อาจติดต่อหลายโฮสต์ โฮสต์ภายในอาจต้องมีข้อยกเว้นแบบ direct ขณะที่โฮสต์สาธารณะใช้พร็อกซี

แยกข้อผิดพลาดของการรับส่งออกจากข้อผิดพลาดของ repository commit ที่ใช้ไม่ได้ การถูก repository ปฏิเสธ และการเชื่อมต่อพร็อกซีล้มเหลว เป็นสาเหตุต่างกันของผลลัพธ์ระดับสูงเดียวกันว่า “อัปเดต submodule ไม่สำเร็จ”