Git 서브모듈의 프록시 라우팅

주 저장소를 성공적으로 복제해도 서브모듈을 검사한 것은 아닙니다. 서브모듈은 다른 Git 저장소이며 다른 호스트와 전송 방식을 사용할 수 있습니다.

선언된 URL부터 읽습니다:

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

HTTPS로 가져온 부모 저장소에 git@host:을 사용하는 서브모듈이 있을 수 있습니다. HTTP 프록시 설정은 해당 SSH 연결을 구성하지 않습니다. 상대 URL은 프로젝트 이름으로 추정한 웹 주소가 아니라 슈퍼프로젝트의 올바른 remote를 기준으로 해석하세요.

저장소별 설정에는 범위가 있습니다

로컬 http.proxy 항목은 그 설정 파일을 포함한 저장소에 속합니다. 부모만 검사해서 초기화된 자식의 모든 유효 설정을 알 수 있다고 가정하지 마세요.

재귀 업데이트에서 임시 HTTPS 프록시를 쓰려면 그 호출에 Git 명령줄 설정을 전달합니다:

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

예시 엔드포인트를 바꾸세요. 공개 프록시가 허용되는 공개 HTTPS 서브모듈은 HTTP 프록시 목록에서 후보 주소를 얻습니다. 이는 SSH URL을 HTTPS로 바꾸지 않으므로 경로가 이상하면 URL별 설정도 확인하세요.

기록된 URL이 바뀐 경우

Git은 초기화 중 서브모듈 설정을 로컬에 등록합니다. 프록시를 탓하기 전에 현재 선언과 로컬 값을 비교하세요. sync 작업은 프로젝트 선언에서 등록 URL을 갱신할 뿐 네트워크 프록시 설정 자체는 아닙니다.

중첩 오류에서는 정확한 경로와 remote를 기록하세요. 재귀 작업은 여러 호스트에 접속할 수 있으며 내부 호스트는 직접 연결 예외, 공개 호스트는 프록시가 필요할 수 있습니다.

전송 오류와 저장소 오류를 구분하세요. 없는 commit, 거부된 접근, 실패한 프록시 연결은 모두 ‘submodule update failed’의 서로 다른 원인입니다.