Skip to main content
obliterate は、パスパターンに一致するファイルの全バージョンについて、あらゆるブランチとコミットにまたがって、その基盤となる blob ストレージを完全に削除します。削除を履歴に記録しつつ古いバージョンを到達可能なまま残す dv rm とは異なり、obliterate はバイト自体を削除し、履歴中の参照を書き換えて blob を復元できないようにします。 次のような場合に使用します:
  • 非常に大きなファイル (ゲームビルド、データセット、誤ってコミットされたバイナリ) がストレージを消費しており、履歴上でもう不要になった場合。
  • シークレット、認証情報、その他の機密ファイルがコミットされてしまい、抹消する必要がある場合。
Obliterate は 破壊的かつ不可逆 です。取り消しはできません。実行前には必ずプレビューを実行し、計画を注意深く確認してください。

​
要件

  • リポジトリ管理者 である必要があります。
  • git 同期されたリポジトリでは obliterate はサポートされていません。

​
仕組み

  1. 1 つ以上のパス glob (例: '/assets/*.psd') を指定します。
  2. サーバーはリポジトリ履歴全体にわたるすべての (パス、バージョン) の一致を解決します。
  3. 各一致は、削除可能 (基盤となる blob は指定した glob に含まれるパスからのみ到達可能) か、削除不可 (同じ blob コンテンツが、含めなかった別のパス経由でも到達可能) のいずれかに分類されます。
  4. 実行時、削除は非同期で走ります。返される job_id をポーリングして進捗を確認できます。
「削除不可」の区分が重要なのは、Diversion がファイル内容をハッシュで格納しているためです — つまり複数のパスで共有される同じバイトは 1 度しか格納されません。同じ内容が指定に含めなかった別のパスにも存在すると、ストレージは残ります。プレビューでは削除を妨げているのがどの別パスかを正確に示します — glob セットを広げて再実行できます。

​
Glob 構文

パターンは リポジトリのルートに固定 されます。ワイルドカードをシェルが展開しないよう、必ずクォートしてください。 パターンが広く固定されていない場合 (たとえばリポジトリ全体に一致する、あるいは再帰の意図があるのに実際にはルートのみに一致する場合) には、プレビューが警告を返します。冗長なパターン (同じ呼び出し内の別のパターンにすでに含まれているもの) も警告対象となります。

​
プレビュー

必ずプレビューから始めてください。サーバー側では何も変更されません。
プレビューは以下を返します:
  • 見出しの件数: 削除可能なバージョン数 / ファイル数、削除不可のバージョン数 / ファイル数、および obliterate が到達できない共有 (グループ化された) ストレージ内の一致件数。
  • 回収見積り: コンテンツハッシュで重複排除された解放バイト数の合計 (同じ blob が N 個のパスにあっても 1 回としてカウント)。
  • 削除可能なパス: パスごとのサマリー — バージョン数と合計バイト数 — 回収サイズが大きい順にソート。
  • 削除不可のパス: パスごとのサマリーに加え、unblock_paths — 同じコンテンツを保持しているリポジトリ内の他のパス。blob を削除したい場合はそれらを glob セットに追加してください。
  • glob ごとのサマリー: 各入力 glob について、それ単独で (glob 間の重複排除前に) 一致したファイル数 / バージョン数 / 合計バイト数。JSON 出力および、複数の glob を渡した場合の人間向け CLI の glob ごとのブロックにのみ表示されます。
  • 警告: glob が広く固定されていない、または冗長である場合に表示されます。
複数の glob を 1 度の呼び出しに渡して、その合算 obliterate 計画を立てられます:

​
人間向け vs JSON 出力

人間向け CLI は、削除可能 / 削除不可のパスをバイト数降順で 上位 20 件 表示し、結果が上限に達した場合は末尾に ... and 980 more (use --json for the full list) のような行を出します。サーバーはバイト降順でソートされた全リストを返し、上限がかかるのは表示のみです。 機械可読な完全な計画を得るには、--json を渡します:
--json は標準出力に単一の JSON ドキュメントを出力し、バナーと警告は抑制されます (警告はドキュメントの warning 文字列フィールドに移動します)。

​
実行

削除しようとしている内容がプレビューと一致したら:
確認のためリポジトリ名または ID を入力するよう求められます。プロンプトをスキップするには --yes を渡します (スクリプト用):
execute は preview と同じ計画に加えて job_id を返し、ジョブが終端状態に達するまでポーリングを開始します。ポーリングの上限は 18 秒 (ステータスエンドポイントを 3 秒ごとに呼び出す) です。短いジョブの場合はインラインで完了を確認でき、長いジョブでは CLI が job_id を表示して終了します。あとは dv obliterate status でフォローアップしてください。 フラグ:
  • --nowait — キューに入れて即座に終了し、ポーリングしない。CLI は job_id を表示し、進捗は自分で確認します。
  • --json — 人間向けバナーではなく単一の JSON ドキュメントを出力する。--yes が必須 — 対話的な確認プロンプトが JSON ストリームを破損させるためです。
終了コード:
execute はジョブがキューに入った時点で返ります — 実際の削除はバックグラウンドで走るため、進捗確認のためにステータスエンドポイントをポーリングします。
obliterate 実行中に同じファイルへ並行して行われるコミットはエッジケースです。他のユーザーが対象パスにアクティブにコミットしている間の obliterate 実行は避けてください。

​
ジョブの追跡

execute するたびに job_id (例: dv.obliterate.593d2b8a8dbf47559bcc73c8bcf54f41) が返されます。以下で進捗を確認します:
レスポンスには全体の status に加え、行ごとの件数が含まれます:

​
ステータス値

ステータスエンドポイントから 404 が返る場合は、そのリポジトリにその ID の obliterate ジョブが存在しないことを意味します。

​
影響を受ける対象

  • 履歴: obliterate されたファイルバージョンはリポジトリの変更ログから削除されます。
  • オープン中のマージ: 競合が obliterate されたファイルを参照していたオープン中のマージは閉じられます。そのまま確定するとデッド参照を持つコミットが生成されるためです。

​
制限

  • preview / execute の解決呼び出しには、サーバー側の時間予算 (60 秒) があります。glob があまりに多くのファイルに一致すると、パターンを絞り込むよう求めるエラーで呼び出しは拒否されます。より具体的な glob セットに作業を分割し、順次実行してください。
  • 共有 (グループ化された) ストレージ に格納されているファイル — 効率化のためにまとめてパックされた小さなファイル — は個別に obliterate できません。プレビューはこれらを別のスキップ数として報告するので、除外された件数が分かります。

​
関連