クローンが Git オブジェクトの転送を完了しても、LFS のコンテンツはまだ欠けていることがある。Git はポインタファイルを保存し、LFS クライアントは大きなオブジェクトについて別々のリクエストを行う。

Git LFS がインストールされた影響を受けるチェックアウトで、そのエンドポイントと最後の失敗を調べる:

git -C project lfs env
git -C project lfs logs last

出力はローカルで確認する。リポジトリの URL とログは、身元を特定できる情報や認証情報を露出する可能性がある。最初に失敗した段階を特定する:

  1. LFS API への接続。
  2. Batch API のダウンロードアクションの取得。
  3. そのアクションのダウンロード URL への到達。これは別のオブジェクトストレージホストや提供されたヘッダーを使用する場合がある。
  4. オブジェクト本体の転送。

リポジトリの LFS エンドポイントの上書き設定と実際の URL の両方を確認する。LFS は独自の HTTP 実装、設定、継承したプロキシ環境を持つ。Git LFS 3.7.0 では、実際のリクエスト URL についてそのプロキシ選択の順序に従う。通常の Git HTTPS ホストへの到達だけでは、その後のすべてのオブジェクト経路を通過したことにはならない。オブジェクトホストの認証失敗は、プロキシ 407 とも別である。

ダウンロードを行うつもりなら、管理されたリポジトリでの別の fetch が、もう一度クローンせずに失敗を明らかにできる:

git -C project lfs fetch

これはオブジェクトを転送するものであり、読み取り専用の設定問い合わせではない。その後、必要なコンテンツが利用可能であることを確認する。部分的なチェックアウトに残った小さなポインタは大きなファイルではなく、以前に成功した Git コマンドは LFS の転送が完了したことを証明できない。

関連記事