git-update-index - ワーキングツリーのファイルコンテンツをインデックスに登録します

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

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

git update-index がファイルを取り扱う方法は、さまざまなオプションを使用して変更できます。

--refresh は新しい sha1 ファイルを計算したり、モード/内容の変更に対してインデックスを最新の状態にしたりしません。しかし、実際に行うこと は、ファイルの 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) を持っています。ファイルシステムがそのいずれかである場合は、変更していないパスに「変更なしと仮定」ビットを設定して、Git がこのチェックを行わないようにすることができます。パスにこのビットを設定しても、Git がファイルの内容をチェックして変更されたかどうかを確認するわけではないことに注意してください。Git は、チェックを省略し、変更されていない と仮定します。ワーキングツリーファイルに変更を加えた場合は、変更する前または後に「変更なしと仮定」ビットを削除して、変更について Git に明示的に通知する必要があります。

「変更なしと仮定」ビットを設定するには、--assume-unchanged オプションを使用します。設定を解除するには、--no-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）で更新されたパスは、自動的に「変更なしと仮定」としてマークされます。「変更なしと仮定」ビットは、git update-index --refresh がワーキングツリーファイルがインデックスと一致することを検出した場合に設定されないことに注意してください（それらを「変更なしと仮定」としてマークする場合は、git update-index --really-refresh を使用します）。

ユーザーは、変更なしと仮定ビットとスキップワーキングツリービットを混同することがあります。違いの説明については、以下の「スキップワーキングツリービット」セクションの最後の段落を参照してください。

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

スキップワーキングツリービットは、（長い）1 つの文で定義できます。可能な限り、ワーキングディレクトリへのファイルの書き込みを回避するように Git に指示し、ワーキングディレクトリにファイルが存在しない場合は、ファイルを変更されていないものとして扱います。

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

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

スキップワーキングツリービットの主な目的は、スパースチェックアウトを有効にすることです。つまり、パスのサブセットのみが存在するワーキングディレクトリを持つことです。スキップワーキングツリービットが設定されている場合、Git コマンド（switch、pull、merge など）はこれらのファイルの書き込みを回避します。ただし、これらのコマンドは、マージまたはリベース中の競合など、重要な場合には、これらのファイルを書き込むことがあります。Git コマンドは、このようなファイルがないことを意図的な削除として扱うことも回避します。たとえば、git add -u はこれらのファイルの削除をステージングせず、git commit -a もそれらを削除するコミットを作成しません。

このビットは変更なしと仮定ビットに似ていますが、その目的は異なります。変更なしと仮定ビットは、ファイルをワーキングツリーに残し、Git が変更のチェックを省略して、ファイルが変更されていないと仮定するためのものです（ただし、ファイルを stat しなくても変更されたことを特定できる場合は、変更を記録できます）。スキップワーキングツリーは、ファイルの不在を無視するように Git に指示し、ワーキングディレクトリの多くを通常更新するコマンド（checkout、switch、pull など）で可能な場合は更新を回避し、不在がコミットに記録されないようにします。スパースチェックアウト（git sparse-checkout で設定するか、core.sparseCheckout を true に設定することで設定）では、ファイルがインデックスでスキップワーキングツリーとしてマークされているが、ワーキングツリーに存在する場合は、Git はそのファイルのスキップワーキングツリービットをクリアすることに注意してください。

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

このモードでは、インデックスは 2 つのファイル、$GIT_DIR/index および $GIT_DIR/sharedindex.<SHA-1> に分割されます。変更は $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）に 1 回設定するだけで、触れるすべてのリポジトリに影響を与えることができます。

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」で多くの「ディレクトリを開けませんでした」という警告が出力される可能性もあります。これらは、以前は黙って破棄されていた既存の問題に対する新しい警告です。

上記で説明したバグと同様に、解決策は、一時的にcore.untrackedCache=falseを指定して「git status」を実行し、残っている不正なデータをフラッシュすることです。

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

これにより、gitは、どのファイルが変更されたかを通知できるファイルシステムモニター（git-fsmonitor--daemon[1]およびgithooks[5]の「fsmonitor-watchman」セクションを参照）と連携できます。これにより、gitは、変更されたファイルを見つけるためにすべてのファイルのlstat()を実行する必要がなくなります。

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

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

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

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

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

このコマンドは、core.ignorestat設定変数を確認します。上記の「変更されていないと仮定」ビットの使用のセクションを参照してください。

このコマンドは、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]スイートの一部