Gitサブモジュールのプロキシ経路

親のGitチェックアウトはプロキシ経由で動くのに子が動かない場合、サブモジュールのURL、転送方式、リポジトリ設定を確認します。

親リポジトリのクローン成功だけではサブモジュールを検証できません。サブモジュールは別のGitリポジトリで、別ホストや別の転送方式を使うことがあります。

宣言されたURLをまず読みます。

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

HTTPSで取得した親にgit@host:を使うサブモジュールが含まれることがあります。HTTPプロキシ設定はそのSSH接続を設定しません。相対URLはプロジェクト名から推測したWebアドレスではなく、スーパープロジェクトの適切な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は初期化時にサブモジュール設定をローカル登録します。URLが変わったら、プロキシの故障と判断する前に現在の宣言と登録値を比較します。syncは宣言から登録URLを更新しますが、ネットワークプロキシ設定ではありません。

入れ子の失敗では、エラーに出た正確なサブモジュールパスとremoteを記録します。再帰処理は複数ホストに接続し、内部ホストは直接接続の例外を、公開ホストはプロキシを必要とすることがあります。

転送エラーとリポジトリエラーを分けてください。存在しないcommit、拒否されたアクセス、プロキシ接続失敗は「submodule update failed」の別々の原因です。

関連記事