git-fsck(1)

SYNOPSIS

git fsck [--tags] [--root] [--unreachable] [--cache] [--no-reflogs]
         [--[no-]full] [--strict] [--verbose] [--lost-found]
         [--[no-]dangling] [--[no-]progress] [--connectivity-only]
         [--[no-]name-objects] [<object>*]

DESCRIPTION

データベース内のオブジェクトの接続性(connectivity)と有効性(validity)を検証します

OPTIONS

<object>: 到達不能追跡のheadとして扱うオブジェクト。

オブジェクトが指定されていない場合、 git fsck はデフォルトでインデックスファイルと、 refs 名前空間内のすべてのSHA-1参照と、(--no-reflogs が与えられて無い場合)すべてのreflogsを、headとして使用します。
--unreachable: 存在するが、どの参照ノードからも到達できないオブジェクトを印刷します。
--[no-]dangling: 存在するが「直接」使用されることのないオブジェクトを印刷します(デフォルト)。 --no-dangling を使用して、この情報を出力から省略することができます。
--root: ルートノードを報告します。
--tags: タグを報告します。
--cache: インデックスに記録されているオブジェクトを、到達不能追跡のheadノードとしても考慮します。
--no-reflogs: reflogのエントリによってのみ参照されるコミットが到達可能であるとは見なさないようにします。このオプションは、以前はrefに含まれていたが、現在は含まれていないが、対応するreflogに残っているコミットを検索することのみを目的としています。
--full: GIT_OBJECT_DIRECTORY（$GIT_DIR/objects) 内のオブジェクトだけでなく、GIT_ALTERNATE_OBJECT_DIRECTORIES または $GIT_DIR/objects/info/alternates にリストされている代替オブジェクトプール、および $GIT_DIR/objects/pack にあるパックされたGitアーカイブにあるオブジェクトもチェックします。サブディレクトリを代替オブジェクトプールにパックします。いまやこれがデフォルトになりました。 --no-full でオフにできます。
--connectivity-only: 到達可能なオブジェクトの接続のみをチェックし、到達可能なタグ、コミット、またはツリーによって参照されるオブジェクトが存在することを確認します。これにより、ブロブの読み取りを完全に回避することで操作が高速化されます(ただし、参照されたブロブが存在するかどうかは引き続きチェックされます)。これにより、コミットとツリーの破損が検出されますが、セマンティックチェック(フォーマットエラーなど)は行われません。ブロブオブジェクトの破損はまったく検出されません。

到達不能なタグ、コミット、およびツリーにもアクセスして、履歴のぶら下がっているセグメントのヒントを見つけることができます。この出力を気にせず、さらに高速化したい場合は、 --no-dangling を使用してください。
--strict: より厳密なチェックを有効にします。つまり、古いバージョンのGitによって作成された g+w ビットセットで記録されたファイルモードをキャッチします。Linuxカーネル、Git自体、スパースリポジトリなどの既存のリポジトリには、このチェックをトリガーする古いオブジェクトがありますが、このフラグを使用して新しいプロジェクトをチェックすることをお勧めします。
--verbose: おしゃべりになります。
--lost-found: タイプに応じて、ぶら下がっているオブジェクトを .git/lost-found/commit/ または .git/lost-found/other/ に書き込みます。オブジェクトがブロブの場合、コンテンツはそのオブジェクト名ではなくファイルに書き込まれます。
--name-objects: 到達可能なオブジェクトの名前を表示する場合、SHA-1に加えて、それらがどのように到達可能であるかを説明する名前も表示します。 git-rev-parse(1) と互換性があります。例えば HEAD@{1234567890}~25^2:src/
--[no-]progress: --no-progress または --verbose が指定されていない限り、進行状況ステータスは、端末に接続されている場合、デフォルトで標準エラーストリームに報告されます。 --progress は、標準エラーストリームが端末に送信されていない場合でも、進行状況出力を強制します。

CONFIGURATION

fsck.<msg-id>: fsck中に、gitは、現在のバージョンのgitでは生成されず、 transfer.fsckObjects が設定されている場合はネットワーク経由で送信されない、レガシーデータの問題を検出する場合があります。この機能は、そのようなデータを含むレガシーリポジトリの操作をサポートすることを目的としています。

fsck.<msg-id> 設定は、 git-fsck(1) によって取得されますが、代わりに、そのようなデータセット receive.fsck.<msg-id> のプッシュを受け入れるか、または、クローンまたはフェッチのセットである fetch.fsck.<msg-id> を使用します。

この文書の残りの部分では、簡潔にするために fsck.* 変数について説明していますが、対応する receive.fsck.* 変数と fetch.<msg-id>.* 変数にも同じことが当てはまります。

color.ui や core.editor のような変数とは異なり、 receive.fsck.<msg-id> と fetch.fsck.<msg-id> 変数は、設定されていない場合、 fsck.<msg-id> 構成にフォールバックしません。さまざまな状況で同じfsck設定を均一に構成するには、3つすべてを同じ値に設定する必要があります。

fsck.<msg-id> が設定されている場合、 fsck.<msg-id> の値を error 、 warn 、ignore のいずれか一つとすることにより、エラーを警告に切り替える事もでき、その逆も可能です。そして <msg-id> の部分はメッセージIDです。便利なように、fsckはエラー/警告メッセージの前にメッセージIDを付けます。たとえば「missingEmail: invalid author/committer line - missing email」は、 fsck.missingEmail = ignore を設定するとその問題が非表示になることを意味します。

一般に、これらの問題のあるオブジェクトが共有する破損の種類をリストして無視するのではなく、 fsck.skipList に問題のある既存のオブジェクトを列挙することをお勧めします。前者を実行すると、同じ破損の新しいインスタンスが見過ごされる可能性があります。

不明な fsck.<msg-id> 値を設定すると、fsckが停止(die)しますが、 receive.fsck.<msg-id> や fetch.fsck.<msg-id> に対して同じことを行うと、gitは単に警告するだけです。
fsck.skipList: 非致命的な理由により既に壊れている(broken)ことが分かっているため無視する必要があるオブジェクト名(1行につき1つの省略されてないSHA-1)のリストへのパス。Git 2.20 以降では、コメント(#)文字から行末までと、空行と、先頭と末尾の空白(whitespace)は無視されます。それより古いバージョンでは1行につき1つのSHA-1以外は全てエラーになります。

この機能は、無効なコミッターの電子メールアドレスなど、初期のコミットにもかかわらず、安全に無視できるエラーを含む、確立されたプロジェクトを受け入れる必要がある場合に役立ちます。注意: この設定では、corruptオブジェクトをスキップすることはできません。

fsck.<msg-id> と同様に、この変数に対応する receive.fsck.skipList 派生と fetch.fsck.skipList 派生があります。

color.ui や core.editor のような変数とは異なり、 receive.fsck.skipList 変数と fetch.fsck.skipList 変数は、設定されていない場合、 fsck.skipList 構成にフォールバックしません。さまざまな状況で同じfsck設定を均一に構成するには、3つすべてを同じ値に設定する必要があります。

古いバージョンのGit(2.20より前)では、オブジェクト名リストを並べ替える必要があることが文書化されています。これは必須ではなく、オブジェクト名は任意の順序で表示できますが、リストを読み取るときに、内部バイナリ検索実装の目的でリストが並べ替えられているかどうかを追跡しました。これにより、既に並べ替えられたリストでは作業を節約できます。膨大なリストがない限り、リストを事前に並べ替える必要はありませんでした。 Gitバージョン2.20以降では、代わりにハッシュ実装が使用されるため、リストを事前に並べ替える必要はありません。

DISCUSSION

git-fsckは、SHA-1と一般的なオブジェクトの健全性をテストし、結果として得られる到達可能性とその他すべてを完全に追跡します。検出した破損(オブジェクトの欠落または不良)を出力し、 --unreachable フラグを使用すると、存在するが指定されたheadノード(または上記デフォルト達)のいずれからも到達できないオブジェクトも出力します。

つまり、それは、あなたのバックアップや、他のアーカイブで見つけなければならない破損したオブジェクトです(つまり、あなたは、それらを削除して、他の誰かが破損したオブジェクトを持っていることを期待して、他のサイトと「rsync」を実行できます)。

core.commitGraph が true の場合、 commit-graph ファイルも「git commit-graph verify」を使用して検査されます。 git-commit-graph(1) を参照してください。

Extracted Diagnostics

unreachable <type> <object>: <type> というタイプである <object> というオブジェクトは、表示されるツリーまたはコミットのいずれにおいても、実際には直接または間接的に参照されていません。これは、指定していない別のルートノードがあるか、ツリーが破損していることを意味している可能性があります。ルートノードを見逃していない場合は、到達不能なノードは使用できないため、削除することをお勧めします。
missing <type> <object>: この <type> というタイプの <object> というオブジェクトは参照されていますが、データベースに存在しません。
dangling <type> <object>: この <type> タイプの <object> というオブジェクトはデータベースに存在しますが、「直接」使用されることはありません。ぶら下がっているコミットはルートノードである可能性があります。
hash mismatch <object>: データベースに、ハッシュがオブジェクトデータベースの値と一致しないオブジェクトがあります。これは、深刻なデータ整合性の問題を示しています。

Environment Variables

GIT_OBJECT_DIRECTORY: オブジェクトデータベースのルート(通常は $GIT_DIR/objects )を指定するために使用されます
GIT_INDEX_FILE: インデックスのインデックスファイルを指定するために使用されます
GIT_ALTERNATE_OBJECT_DIRECTORIES: 追加のオブジェクトデータベースルートを指定するために使用されます(通常は未設定)

GIT

Part of the git(1) suite

git-fsck(1) Manual Page

NAME