テクノロジー · 実用ガイド
Gitの「No url found for submodule path」：削除前にgitlinkと.gitmodulesを確認
失敗したコミット、現在のインデックス、記録された対応付け、ローカル状態を比較し、修復・同期・deinit・削除を選びます。
「No url found for submodule path」が出たら、Gitの管理情報を削除する前にパスとURLの対応を確認します。子コミットを記録するgitlinkと.gitmodulesの設定は別の状態です。現在のインデックス、ディスク上のファイル、失敗したコミットが一致するとは限りません。
元のエラー、失敗した親リポジトリのコミット、パス、ローカルの作業を保存します。コミット済みのgitlinkと対応付けを確認してからローカル設定を調べ、リポジトリが意図する処置を選びます。Git2.51.1の隔離実験は、ディスク上のファイルが正しくても失敗コミットは直らない例を示します。
失敗コミットと現在のインデックスを分ける
エラー全文を保存し、失敗したチェックアウトやCIが実際に使用した親コミットを特定します。親リポジトリのルートで作業し、書き込み前に未コミットの変更を保護します。git ls-files --stage -- path/to/itemで現在のインデックスを確認。モード160000はgitlinkとそのオブジェクトIDを示します。入れ子の.gitディレクトリだけでは判定できません。
続いてgit ls-tree --full-tree COMMIT -- path/to/itemを実行し、COMMITを確認した失敗コミットIDに置き換えます。これは現在のインデックスが一致すると仮定せず、そのツリーを読みます。そこにgitlinkがなければ、別のチェックアウト、入れ子の親リポジトリ、ステージ済み変更、エラーに出たパスを調べてから修復を決めます。
同じコミットから対応付けを読む
git show COMMIT:.gitmodulesで失敗コミット内のファイルを確認します。ファイルがないこと自体が証拠で、別ブランチの内容を無言で代用してはいけません。gitlinkと大文字小文字まで一致するpathの節を探します。Gitは一意のルート相対パス、末尾スラッシュなし、URLを要求します。節名はパスと同一でなくても構いません。
現在の作業ファイルには、互換性のあるgit config -f .gitmodules --get-regexp '^submodule\..*\.(path|url)$'が使えます。正規表現を引用符で囲み、シェルが|をパイプと解釈しないようにします。コミット内のファイルと比較してください。ディスクに未コミットのファイルを戻しても、失敗コミットを新規チェックアウトした内容は変わりません。
ローカル設定を分離し、意図したURLだけ同期
git config --local --get-regexp '^submodule\..*\.(url|active)$'で初期化済みのローカル設定を別に確認します。キーはサブモジュール名を使うので、.gitmodulesのpathと対応させます。初期化は記録されたテンプレートから設定できますが、後のローカル上書きは異なる場合があります。deinit済みでも定義が残り、ファイルがない状態はあり得ます。
既存URLを意図的に変更した場合は、承認されたリモートを確認して.gitmodulesを修正し、対象の初期化済みサブモジュールにgit submodule sync --recursive -- path/to/itemを実行します。update前に有効なURLを確認します。syncは登録済みURLの同期であり、欠落した対応付けの修復、子コミットの変更、非公開リモートの認可は行いません。
維持・ローカル削除・記録からの削除を選ぶ
維持するなら正確なpathと承認済みURLを戻し、ステージして差分を確認し、意図した修復コミットを作ります。その後に初期化・更新し、修復コミットのクリーンなチェックアウトで確認します。URLだけの変更なら、子コミット更新も意図していない限りgitlinkを保ち、影響する初期化済み環境を同期します。
ローカルのチェックアウトだけを外すなら作業を保護してgit submodule deinit -- path/to/itemを使い、変更を捨てる--forceを追加しません。バージョン管理から削除するならgit rm -- path/to/itemを使い、gitlinkの削除と.gitmodules節の変更を確認してコミットします。git rm --cachedはインデックスのみで、通常のgit rmと同じ自動対応付け削除はしません。
キャッシュより先にクリーンクローンで確認
隔離したGit2.51.1リポジトリで、対応付けなしのgitlinkをコミットすると、新規ローカルクローンで同じfatalエラーが再現しました。インデックスとコミットツリーはともに160000。ディスクだけに.gitmodulesを戻すと作業ファイルの検査は成功しても、失敗コミットのgit showは失敗したままでした。復元した対応付けをコミットするとクリーンクローンの初期化が成功し、その後deinitしてもコミット済みgitlinkと対応付けは不変でした。
実験はローカル子リポジトリのみで、各実験コマンドだけfile転送を許可しました。CI、ネットワーク、非公開認可の再現ではなく、この上書きは本番修復策ではありません。コミット済み情報が正しくなってから使い捨てチェックアウトの古い状態を疑います。ログと作業を保存し、適切なら使い捨て部分だけ再作成して、失敗・修復コミットとクリーンクローン結果を記録します。.git/modules、入れ子の.git、開発者の作業ツリーの削除から始めないでください。
