SYNOPSIS

git sparse-checkout <subcommand> [options]

DESCRIPTION

スパース(まばらな)チェックアウト構成を初期化および変更します。これにより、チェックアウトがパターンのリストで指定されたパスのセットに削減されます。

警告: このコマンドは実験的なものです。 その動作、およびスパースチェックアウトの存在下での他のコマンドの動作は、将来変更される可能性があります。

COMMANDS

list

sparse-checkoutファイルにパターンを記述します。

init

core.sparseCheckout 設定を有効にします。スパースチェックアウトファイル(sparse-checkout file)が存在しない場合は、ルートディレクトリ内のすべてのファイルに一致し、他のディレクトリには一致しないパターンをスパースチェックアウトファイルに入力すると、Gitによって追跡されるすべてのディレクトリが削除されます。 スパースチェックアウトファイルにパターンを追加して、作業ディレクトリに再設定します。

他のワークツリーへの干渉を避けるために、最初に extensions.worktreeConfig 設定を有効にし、ワークツリー固有の構成ファイルで必ず core.sparseCheckout 設定を設定します。

--cone を指定すると、 core.sparseCheckoutCone 設定も設定され、限定パターンのセットでパフォーマンスが向上します(下記の「CONE PATTERN SET」参照)。

--[no-]sparse-index オプションを使用して、スパースインデックス形式の使用を切り替えます。 これにより、インデックスのサイズが縮小され、スパースチェックアウト定義とより緊密に連携します。 これにより、gits tatus や git add などのコマンドのパフォーマンスが大幅に向上する可能性があります。 注意: この機能はまだ実験段階です。 一部のコマンドは、機能と適切に統合されるまで、インデックスがまばら(sparse)であると遅くなる可能性があります。

Warning
 スパースインデックスを使用するには、外部ツールでは完全には理解できない方法でインデックスを変更する必要があります。 この互換性に問題がある場合は、 git sparse-checkout init --no-sparse-index を実行して、インデックスがまばらにならないように書き換えます。 古いバージョンのGitは、スパースディレクトリエントリのインデックス拡張機能を理解せず、それが無効になるまでリポジトリとのやり取りに失敗する可能性があります。
set

setサブコマンドに続く引数のリストとして与えられた一連のパターンをスパースチェックアウトファイルに書き込みます。 新しいパターンに一致するように作業ディレクトリを更新します。 core.sparseCheckout 構成設定がまだ有効になっていない場合は、有効にします。

--stdin オプションを指定すると、パターンは引数からではなく、改行で区切られたリストとして標準入力から読み込まれます。

core.sparseCheckoutCone が有効になっている場合、入力リストはスパースチェックアウトパターンではなくディレクトリのリストと見なされます。 このコマンドは、スパースチェックアウトファイルにパターンを書き込み、それらのディレクトリに含まれるすべてのファイル(と、以下のディレクトリを再帰的にたどります)と、祖先ディレクトリの兄弟であるファイルを含めます。 入力形式は、 git ls-tree --name-only の出力と一致します。 これには、二重引用符(")で始まるパス名をCスタイルの引用符で囲まれた文字列として解釈することが含まれます。

add

スパースチェックアウトファイルを更新して、追加のパターンを含めます。 デフォルトでは、これらのパターンはコマンドライン引数から読み取られますが、 --stdin オプションを使用して標準入力から読み取ることができます。 core.sparseCheckoutCone が有効になっている場合、指定されたパターンはsetサブコマンドのようにディレクトリ名として解釈されます。

reapply

作業ツリーのパスにスパースパターンルールを再適用します。 マージやリベースなどのコマンドは、作業を行うためのパスを具体化でき(たとえば、競合を表示するため)ますが、他のスパースチェックアウトコマンドは、個々のファイルをスパース化できない場合があります(たとえば、ステージングされていない変更や競合があるため)。 このような場合、影響を受けるパスをクリーンアップした後、(たとえば、競合の解決、変更の取り消しまたはコミットなどの)後で git sparse-checkout reapply を実行するのが理にかなっています。

disable

core.sparseCheckout 構成設定を無効にし、すべてのファイルを含めるように作業ディレクトリを復元(restore)します。 その後 git sparse-checkout init コマンドで作業ディレクトリが同じ状態に戻る可能性があるため、スパースチェックアウトファイルはそのまま残します。

SPARSE CHECKOUT

「sparse checkout」(まばらなチェックアウト)を使用すると、作業ディレクトリにまばらにデータを入力できます。 skip-worktreeビット(git-update-index(1) 参照)を使用して、作業ディレクトリ内のファイルを確認する価値があるかどうかをGitに通知します。 skip-worktreeビットが設定されている場合、作業ディレクトリのファイルは無視されます。 Git はこれらのファイルの内容を入力しないので、多くのファイルがあるリポジトリで作業しているが、現在のユーザーにとって重要なものはごくわずかである場合に、まばらなチェックアウトが役に立ちます。

$GIT_DIR/info/sparse-checkout ファイルは、スキップワークツリー参照ビットマップを定義するために使用されます。 Gitが作業ディレクトリを更新すると、このファイルに基づいてインデックスのスキップワークツリービットが更新されます。 ファイル内のパターンに一致するファイルは作業ディレクトリに表示され、残りは表示されません。

スパースチェックアウト機能を有効にするには、 git sparse-checkout init を実行してシンプルなスパースチェックアウトファイルを初期化し、 core.sparseCheckout 構成設定を有効にします。 次に、 git sparse-checkout set を実行して、スパースチェックアウトファイルのパターンを変更します。

作業ディレクトリにすべてのファイルを再入力するには、 git sparse-checkou tdisable コマンドを使用します。

FULL PATTERN SET

デフォルトでは、sparse-checkoutファイルは .gitignore ファイルと同じ構文を使用します。

通常、 $GIT_DIR/info/sparse-checkout は、含まれるファイルを指定するために使用されますが、ネガティブパターンを使用して、「含まれない」ファイルを指定することもできます。 たとえば、ファイル unwanted を削除するには以下のようにします:

/*
!unwanted

CONE PATTERN SET

フルパターンセットにより、任意のパターンの一致と複雑な包含/除外ルールが可能になります。 これらにより、インデックスを更新するときに O(オー;N*M)パターンが一致する可能性があります。ここで、Nはパターンの数、Mはインデックス内のパスの数です。 このパフォーマンスの問題に対処するために、 core.sparseCheckoutCone が有効になっている場合は、より制限されたパターンセットが許可されます。

円錐(cone)パターンセットで受け入れられるパターンは以下のとおりです:

  1. 再帰: (recursive)ディレクトリ内のすべてのパスが含まれます

  2. 親: (parent)ディレクトリ直下のすべてのファイルが含まれます。

上記の2つのパターンに加えて、ルートディレクトリ内のすべてのファイルが含まれていることも期待されます。再帰(recursive)パターンが追加されると、すべての先行ディレクトリが親(parent)パターンとして追加されます。

デフォルトでは、 git sparse-checkout init を実行すると、ルートディレクトリが親パターンとして追加されます。 この時点で、スパースチェックアウトファイルには以下のパターンが含まれています:

/*
!/*/

これは、「ルートは全てインクルードするが、ルートの2レベル下は何も含めない」という意味です。

円錐(cone)モードの場合、 git sparse-checkout set サブコマンドは、スパースチェックアウトパターンのリストではなく、ディレクトリのリストを取得します。 このモードでは、コマンド git sparse-checkout set A/B/C は、ディレクトリ A/B/C を再帰パターンとして設定し、ディレクトリ A と A/B は親パターンとして追加されます。 結果のスパースチェックアウトファイルは以下のようになります

/*
!/*/
/A/
!/A/*/
/A/B/
!/A/B/*/
/A/B/C/

ここでは順番が重要なので、ネガティブなパターンはファイルの下位に表示されるポジティブなパターンに上書きされます。

core.sparseCheckoutCone=true の場合、Gitはこれらのタイプのパターンを期待してスパースチェックアウトファイルをパースします。 パターンが一致しない場合、Gitは警告を発します。 パターンが期待される形式と一致する場合、Gitはより高速なハッシュベースのアルゴリズムを使用して、スパースチェックアウトに含めるモノを計算します。

円錐(cone)モードの場合、 git sparse-checkout list サブコマンドは、再帰(recursive)パターンを定義するディレクトリを一覧表示します。 上記のスパースチェックアウトファイルの例の場合、出力は以下のようになります:

$ git sparse-checkout list
A/B/C

core.ignoreCase=true の場合、パターンマッチングアルゴリズムは大文字と小文字を区別しないチェックを使用します。 これにより、 git sparse-checkout set コマンドのファイル名が一致しない状況が修正され、作業ディレクトリに期待される円錐(cone)が反映されます。

円錐(cone)モードでスパースチェックアウトパターンを変更すると、Gitはスパースチェックアウト円錐(cone)内にない追跡中の各ディレクトリを検査して、追跡されていないファイルが含まれているかどうかを確認します。 .gitignore パターンが原因でこれらのファイルがすべて無視された場合、ディレクトリは削除されます。 そのディレクトリ内の追跡されていないファイルのいずれかが無視されない場合、そのディレクトリ内で削除は発生せず、警告メッセージが表示されます。 これらのファイルが重要な場合は、スパースチェックアウト定義をリセットして含まれるようにし、 git add と git commit を使用してファイルを保存し、残りのファイルを手動で削除して、Gitが最適に動作できるようにします。

SUBMODULES

あなたのリポジトリに1つ以上のサブモジュールが含まれている場合、サブモジュールは git submodule コマンドとの相互作用に基づいて入力されます。 具体的には、 git submodule init -- <path> は <path> のサブモジュールが存在することを確認し、 git submodule deinit [-f] -- <path> は <path> のサブモジュールのファイルを削除します(追跡されていないファイル、コミットされていない変更、プッシュされていない履歴を含む)。sparse-checkoutが作業ツリーからファイルを削除するが、インデックスにエントリを残す方法と同様に、初期化されていないサブモジュールは作業ディレクトリから削除されますが、インデックスにはエントリがあります。

サブモジュールにはプッシュされていない変更または追跡されていないファイルがある可能性があるため、それらを削除するとデータが失われる可能性があります。 したがって、スパース 包含/除外 ルールを変更しても、すでにチェックアウトされているサブモジュールが作業コピーから削除されることはありません。 別の言い方をすれば、サブモジュールを削除または追加するブランチを切り替えても、 checkout によってサブモジュールが自動的に削除または初期化されないのと同様に、 sparse-checkout を使用して「興味深い」ファイルの範囲を縮小または拡大してもサブモジュールの自動的な非初期化または初期化は発生しません。

さらに、上記の事実は、「追跡された」ファイルが作業コピーに存在しない可能性に複数の理由があることを意味します。スパースチェックアウトからのスパースパターンアプリケーション、およびサブモジュールの初期化状態です。 したがって、作業コピー内の追跡されたファイルで機能する git grep のようなコマンドは、これらの制限のいずれかまたは両方によって制限される結果を返す可能性があります。

SEE ALSO

git-read-tree(1) gitignore(5)

GIT

Part of the git(1) suite