ניתוב פרוקסי לתת־מודולים של Git

שכפול מוצלח של המאגר הראשי אינו בודק את תתי־המודולים שלו. תת־מודול הוא מאגר Git אחר, שעשוי להיות במארח אחר ולהשתמש בתעבורה אחרת.

התחילו בקריאת הכתובות המוצהרות:

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

מאגר אב שנשלף ב-HTTPS עשוי להכיל תת־מודול המשתמש ב-git@host:. הגדרת פרוקסי HTTP אינה מגדירה את חיבור ה-SSH הזה. גם כתובות יחסיות של תתי־מודולים יש לפתור מול ה-remote המתאים של פרויקט־העל, ולא מול כתובת אינטרנט שהסקתם משם הפרויקט.

להגדרות מקומיות של מאגר יש תחום תחולה

רשומת http.proxy מקומית שייכת למאגר שקובץ ההגדרות שלו מכיל אותה. אל תניחו שבדיקת האב בלבד חושפת את כל ההגדרות האפקטיביות במאגר צאצא שאותחל.

כדי לעקוף זמנית את הגדרת פרוקסי HTTPS בעדכון רקורסיבי, אפשר להעביר לקריאה הזאת הגדרות Git בשורת הפקודה:

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

החליפו את נקודת הקצה לדוגמה. לתת־מודולים ציבוריים ב-HTTPS במסלול שבו מותר להשתמש בפרוקסי ציבורי, רשימת פרוקסי HTTP מספקת כתובות מועמדות. הפעולה אינה ממירה כתובות SSH ל-HTTPS, וכדאי לבדוק גם הגדרה ספציפית יותר לפי URL אם המסלול שנבחר מפתיע.

כשהכתובת הרשומה השתנתה

Git רושם מקומית את הגדרות תת־המודול בזמן האתחול. אם הכתובת בפרויקט השתנתה, השוו את ההצהרה הנוכחית לערך הרשום מקומית לפני שמחליטים שהפרוקסי לא עובד. פעולת sync המתועדת מעדכנת כתובות רשומות מהצהרת הפרויקט; היא עצמה אינה הגדרת פרוקסי רשת.

בכשל מקונן, רשמו את הנתיב המדויק של תת־המודול ואת ה-remote המופיע בשגיאה. פעולה רקורסיבית עשויה לפנות לכמה מארחים; מארח פנימי עשוי לדרוש חריג לחיבור ישיר, בזמן שמארח ציבורי משתמש בפרוקסי.

הפרידו שגיאות תעבורה משגיאות מאגר. commit שאינו זמין, סירוב גישה מצד המאגר וכשל בחיבור לפרוקסי הם סיבות שונות לאותה תוצאה כללית: ‘submodule update failed’.