git-update-index - 作業ツリーのファイル内容をインデックスに登録する

インデックスを変更します。指定された各ファイルはインデックスに更新され、未マージまたは更新が必要な状態はクリアされます。

インデックスの最も一般的な操作をよりユーザーフレンドリーな方法で行うには、git-add[1] も参照してください。

git update-index が指定されたファイルを処理する方法は、様々なオプションで変更できます

--refresh は、新しい sha1 ファイルを計算したり、モード/コンテンツの変更のためにインデックスを最新の状態にしたりすることはありません。しかし、--refresh はファイルの stat 情報をインデックスと「再一致」させるので、変更されていないファイルでも stat エントリが古い場合にインデックスを更新できます。

たとえば、git read-tree を実行した後、stat インデックスの詳細を適切なファイルにリンクするためにこれを行いたいでしょう。

--cacheinfo は、現在の作業ディレクトリにないファイルを登録するために使用されます。これは、最小限のチェックアウトマージに役立ちます。

モードと sha1 を持つパスにファイルがあるふりをするには、次のようにします。

--info-only は、オブジェクトデータベースに配置せずにファイルを登録するために使用されます。これは、ステータスのみのリポジトリに役立ちます。

--cacheinfo と --info-only は両方とも同様に動作します。インデックスは更新されますが、オブジェクトデータベースは更新されません。--cacheinfo は、オブジェクトがデータベースにあるがファイルがローカルで利用できない場合に役立ちます。--info-only は、ファイルが利用可能であるが、オブジェクトデータベースを更新したくない場合に役立ちます。

--index-info は、標準入力から複数のエントリ定義を供給できる、より強力なメカニズムであり、特にスクリプト用に設計されています。次の3つの形式の入力を受け取ることができます。

上位ステージのエントリをインデックスに配置するには、まずパスの mode=0 エントリを供給してパスを削除し、次に3番目の形式で必要な入力行を供給する必要があります。

たとえば、このインデックスから開始すると

--index-info に次の入力を与えることができます

入力の最初の行は、パスを削除するためにモードとして0を与えます。SHA-1 は適切にフォーマットされている限り重要ではありません。次に、2行目と3行目は、そのパスのステージ1とステージ2のエントリを与えます。上記の後、次のようになります。

Git の多くの操作は、ファイルシステムに効率的な lstat(2) 実装があることに依存しており、作業ツリーファイルの st_mtime 情報を安価にチェックして、ファイルの内容がインデックスファイルに記録されているバージョンから変更されたかどうかを確認できるようにしています。残念ながら、一部のファイルシステムには非効率な lstat(2) があります。もしお使いのファイルシステムがその一つである場合、変更していないパスに「assume unchanged」ビットを設定することで、Git がこのチェックを行わないようにすることができます。このビットをパスに設定しても、Git がファイルの内容をチェックして変更されたかどうかを確認するわけではないことに注意してください。Git は一切のチェックを省略し、変更されていないと 仮定 します。作業ツリーのファイルを変更する場合は、変更する前または後に「assume unchanged」ビットを解除して、明示的に Git にそのことを伝える必要があります。

「assume unchanged」ビットを設定するには、--assume-unchanged オプションを使用します。解除するには、--no-assume-unchanged を使用します。「assume unchanged」ビットが設定されているファイルを確認するには、git ls-files -v を使用します ( git-ls-files[1] 参照)。

このコマンドは core.ignorestat 設定変数を参照します。これが true の場合、git update-index paths... で更新されたパス、およびインデックスと作業ツリーの両方を更新する他の Git コマンド (例: git apply --index、git checkout-index -u、git read-tree -u) で更新されたパスは、自動的に「assume unchanged」としてマークされます。「assume unchanged」ビットは、git update-index --refresh が作業ツリーのファイルがインデックスと一致すると判断した場合、設定されない ことに注意してください (git update-index --really-refresh を使用して「assume unchanged」としてマークしたい場合)。

ユーザーは時々、assume-unchanged ビットと skip-worktree ビットを混同します。違いの説明については、以下の「Skip-worktree bit」セクションの最後の段落を参照してください。

既にチェックアウトされているファイルのみを更新およびリフレッシュするには

Skip-worktree ビットは、一つの (長い) 文で定義できます。合理的に可能な限りファイルを作業ディレクトリに書き込まないように Git に指示し、作業ディレクトリにファイルが存在しない場合は変更されていないものとして扱います。

すべての Git コマンドがこのビットに注意を払うわけではなく、一部は部分的にしかサポートしていないことに注意してください。

skip-worktree ビットに関連する update-index フラグと read-tree 機能は、git-sparse-checkout[1] コマンドが導入される前から存在していました。このコマンドは、skip-worktree ビットを設定および処理するはるかに簡単な方法を提供します。リポジトリ内のファイルの一部のみを扱うように作業ツリーを減らしたい場合は、低レベルの update-index および read-tree プリミティブよりも git-sparse-checkout[1] の使用を強くお勧めします。

skip-worktree ビットの主な目的は、sparse checkouts を有効にすること、つまり、パスの一部のみが存在する作業ディレクトリを持つことです。skip-worktree ビットが設定されている場合、Git コマンド (例: switch、pull、merge) はこれらのファイルを書き込みません。ただし、マージまたはリベース中の競合など、重要なケースではこれらのコマンドがこれらのファイルを書き込むことがあります。また、Git コマンドは、これらのファイルの欠如を意図的な削除として扱いません。たとえば、git add -u はこれらのファイルの削除をステージングせず、git commit -a もそれらを削除するコミットを作成しません。

このビットは assume-unchanged ビットと似ていますが、その目的は異なります。assume-unchanged ビットは、ファイルを作業ツリーに残したまま、Git がその変更をチェックするのを省略し、ファイルが変更されていないと推定するためです (ただし、ファイルを stat せずに変更されたと判断できる場合は、変更を自由に記録できます)。skip-worktree は、Git にファイルの欠如を無視させ、通常作業ディレクトリの多くを更新するコマンド (例: checkout、switch、pull など) で可能な限り更新を避け、その欠如がコミットに記録されないようにします。疎なチェックアウト ( git sparse-checkout または core.sparseCheckout を true に設定することで設定) では、インデックスでファイルが skip-worktree とマークされているにもかかわらず作業ツリーで見つかった場合、Git はそのファイルの skip-worktree ビットをクリアすることに注意してください。

このモードは、非常に大きなインデックスを持つリポジトリ向けに設計されており、これらのインデックスを繰り返し書き込むのにかかる時間を短縮することを目的としています。

このモードでは、インデックスは `$GIT_DIR/index` と `$GIT_DIR/sharedindex.` の2つのファイルに分割されます。変更はスプリットインデックスである `$GIT_DIR/index` に蓄積され、共有インデックスファイルはすべてのインデックスエントリを含み、変更されません。

スプリットインデックス内のすべての変更は、スプリットインデックス内のエントリ数が splitIndex.maxPercentChange 設定変数 ( git-config[1] 参照) で指定されたレベルに達すると、共有インデックスファイルにプッシュバックされます。

新しい共有インデックスファイルが作成されるたびに、その修正時刻が splitIndex.sharedIndexExpire 設定変数 ( git-config[1] 参照) で指定されたものよりも古い場合、古い共有インデックスファイルは削除されます。

まだ使用されている共有インデックスファイルを削除しないように、新しいスプリットインデックスが共有インデックスファイルに基づいて作成または読み込まれるたびに、その修正時刻は現在の時刻に更新されます。

このキャッシュは、git status のような、追跡されていないファイルを特定するコマンドの速度を向上させることを目的としています。

この機能は、作業ツリーディレクトリの mtime を記録し、mtime が変更されていないディレクトリ内のファイルを読み込んだり、stat 呼び出しを行ったりするのを省略することで機能します。これが機能するためには、基盤となるオペレーティングシステムとファイルシステムが、ディレクトリ内のファイルが追加、変更、または削除された場合にディレクトリの st_mtime フィールドを変更する必要があります。

ファイルシステムがそれをサポートしているかどうかは、--test-untracked-cache オプションでテストできます。--untracked-cache オプションは、Git の以前のバージョンでは暗黙的にそのテストを実行していましたが、現在はそうではありません。

この機能を有効 (または無効) にしたい場合は、各リポジトリで git update-index の --untracked-cache オプションを使用するよりも、core.untrackedCache 設定変数 ( git-config[1] 参照) を使用する方が簡単です。特に、使用するすべてのリポジトリでそうしたい場合は、$HOME/.gitconfig で一度 true (または false) に設定するだけで、操作するすべてのリポジトリに影響を与えることができます。

core.untrackedCache 設定変数が変更された場合、次にコマンドがインデックスを読み込むときに追跡されていないキャッシュがインデックスに追加または削除されます。一方、--[no-|force-]untracked-cache が使用された場合、追跡されていないキャッシュは直ちにインデックスに追加または削除されます。

2.17以前の追跡されていないキャッシュには、ディレクトリを別のディレクトリへのシンボリックリンクで置き換えると、Git によって追跡されているファイルを追跡されていないものとして誤って表示するバグがありました。git.git の「status: add a failing test showing a core.untrackedCache bug」コミットを参照してください。その回避策は (そしてこれは将来発見される他のバグにも機能するかもしれません)

このバグは、追跡されていないキャッシュの内部構造に関する限り、ディレクトリをファイルで置き換える非シンボリックリンクのケースにも影響することが示されていますが、これが間違った「git status」出力につながったケースは報告されていません。

また、2.17より前のGitバージョンで書き込まれた既存のインデックスが、もはや存在しないディレクトリを参照しているケースもあり、「git status」で多くの「could not open directory」警告が印刷される可能性があります。これらは、以前は静かに破棄されていた既存の問題に対する新しい警告です。

上記のバグと同様に、解決策は、残りの不良データをフラッシュするために、core.untrackedCache=false を使用して「git status」を一度実行することです。

この機能は、大規模な作業ディレクトリを持つリポジトリの Git 操作を高速化することを目的としています。

これにより、Git はファイルシステムモニター (git-fsmonitor--daemon[1] および githooks[5] の「fsmonitor-watchman」セクションを参照) と連携して、どのファイルが変更されたかを通知することができます。これにより、Git はすべてのファイルを lstat() して変更されたファイルを検索する手間を省くことができます。

追跡されていないキャッシュと組み合わせて使用​​すると、作業ディレクトリ全体をスキャンして新しいファイルを探すコストを回避できるため、パフォーマンスをさらに向上させることができます。

この機能を有効 (または無効) にしたい場合は、各リポジトリで git update-index の --fsmonitor オプションを使用するよりも、core.fsmonitor 設定変数 ( git-config[1] 参照) を使用する方が簡単です。特に、使用するすべてのリポジトリでそうしたい場合は、$HOME/.gitconfig で一度設定変数を設定するだけで、操作するすべてのリポジトリに影響を与えることができます。

core.fsmonitor 設定変数が変更された場合、次にコマンドがインデックスを読み込むときにファイルシステムモニターがインデックスに追加または削除されます。--[no-]fsmonitor が使用された場合、ファイルシステムモニターは直ちにインデックスに追加または削除されます。

このコマンドは core.filemode 設定変数を尊重します。リポジトリが実行可能ビットが信頼できないファイルシステム上にある場合、これは false に設定する必要があります ( git-config[1] 参照)。これにより、コマンドは、インデックスに記録されたファイルモードとファイルシステムのファイルモードが実行可能ビットのみで異なる場合、それらの違いを無視します。そのような不運なファイルシステムでは、git update-index --chmod= を使用する必要があるかもしれません。

同様に、core.symlinks 設定変数が false に設定されている場合 ( git-config[1] 参照)、シンボリックリンクは通常のファイルとしてチェックアウトされ、このコマンドは記録されたファイルモードをシンボリックリンクから通常のファイルに修正しません。

このコマンドは core.ignorestat 設定変数を参照します。上記の「"assume unchanged" ビットの使用」セクションを参照してください。

このコマンドは core.trustctime 設定変数も参照します。inode 変更時刻が Git の外部で定期的に変更される場合 (ファイルシステムクローラーやバックアップシステムは処理されたファイルをマークするために ctime を使用します) に役立ちます ( git-config[1] 参照)。

追跡されていないキャッシュ拡張機能は、core.untrackedCache 設定変数 ( git-config[1] 参照) で有効にできます。

ユーザーは、追跡されているファイルへの変更を Git に無視させるために、assume-unchanged および skip-worktree ビットを使用しようとすることがよくあります。これは期待どおりには機能しません。Git は特定の操作を実行するときに、作業ツリーのファイルをインデックスと比較する場合があります。一般的に、Git は追跡されているファイルへの変更を無視する方法を提供しないため、代替ソリューションが推奨されます。

たとえば、変更したいファイルが設定ファイルの一種である場合、リポジトリにはサンプル設定ファイルを含めることができ、それを無視された名前にコピーして変更できます。リポジトリには、サンプルファイルをテンプレートとして扱い、自動的に変更してコピーするスクリプトを含めることさえできます。

git-config[1], git-add[1], git-ls-files[1]

git[1]スイートの一部