SYNOPSIS

git update-index
             [--add] [--remove | --force-remove] [--replace]
             [--refresh] [-q] [--unmerged] [--ignore-missing]
             [(--cacheinfo <mode>,<object>,<file>)…]
             [--chmod=(+|-)x]
             [--[no-]assume-unchanged]
             [--[no-]skip-worktree]
             [--[no-]ignore-skip-worktree-entries]
             [--[no-]fsmonitor-valid]
             [--ignore-submodules]
             [--[no-]split-index]
             [--[no-|test-|force-]untracked-cache]
             [--[no-]fsmonitor]
             [--really-refresh] [--unresolve] [--again | -g]
             [--info-only] [--index-info]
             [-z] [--stdin] [--index-version <n>]
             [--show-index-version]
             [--verbose]
             [--] [<file>…]

DESCRIPTION

インデックスを変更します。 言及された各ファイルはインデックスに更新され、「unmerged」(マージされていない)または「needs updating」(更新が必要)状態がクリアされます。

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

git update-index が通知されたファイルを処理する方法は、さまざまなオプションを使用して変更できます:

OPTIONS

--add

指定のファイルがまだインデックスにない場合は、追加されます。 デフォルトの動作では、新規ファイルは無視されます。

--remove

If a specified file is in the index but is missing then it’s removed. Default behavior is to ignore removed files.

--refresh

現在のインデックスを調べ、 stat() 情報をチェックして、マージまたは更新が必要かどうかを確認します。

-q

静かにします。 もし --refresh がインデックスの更新を必要としていると判断した場合、デフォルトの動作はエラーになります。 このオプションは、 git update-index をとにかく継続させます。

--ignore-submodules

サブモジュールを更新しようと試みない。このオプションは、--refresh より前に渡された場合にのみ尊重されます。

--unmerged

--refresh がインデックス内のマージされていない変更を検出した場合、デフォルトの動作はエラー終了です。 このオプションにより、「git update-index」はとにかく続行されます。

--ignore-missing

--refresh の処理中に欠落しているファイルを無視します

--cacheinfo <mode>,<object>,<path>
--cacheinfo <mode> <object> <path>

指定の情報を直接インデックスに挿入します。 下位互換性のために、これらの3つの引数を3つの別個のパラメーターとして指定することもできますが、新しいユーザーは単一パラメーター形式を使用することをお勧めします。

--index-info

stdinからインデックス情報を読み取ります。

--chmod=(+|-)x

更新されたファイルに実行権限を設定します。

--[no-]assume-unchanged

When this flag is specified, the object names recorded for the paths are not updated. Instead, this option sets/unsets the "assume unchanged" bit for the paths. When the "assume unchanged" bit is on, the user promises not to change the file and allows Git to assume that the working tree file matches what is recorded in the index. If you want to change the working tree file, you need to unset the bit to tell Git. This is sometimes helpful when working with a big project on a filesystem that has a very slow lstat(2) system call (e.g. cifs).

インデックス内のこのファイルを変更する必要がある場合、例えばコミットにマージするとき、Gitは(正常に)失敗します。 したがって、追跡されていないと仮定されるファイルがアップストリームで変更された場合、あなたは状況を手動で処理する必要があります。

--really-refresh

--refresh と同様ですが、「assume unchanged」設定に関係なく、統計情報を無条件にチェックします。

--[no-]skip-worktree

When one of these flags is specified, the object names recorded for the paths are not updated. Instead, these options set and unset the "skip-worktree" bit for the paths. See section "Skip-worktree bit" below for more information.

--[no-]ignore-skip-worktree-entries

--remove オプションが指定されている場合でも、 skip-worktree (別名「インデックスのみ」) エントリを削除しないでください。

--[no-]fsmonitor-valid

When one of these flags is specified, the object names recorded for the paths are not updated. Instead, these options set and unset the "fsmonitor valid" bit for the paths. See section "File System Monitor" below for more information.

-g
--again

Runs git update-index itself on the paths whose index entries are different from those of the HEAD commit.

--unresolve

誤ってクリアされた場合、マージ処理中のファイルの「unmerged」(マージされていない)または「needs updating」(更新が必要)状態を復元します。

--info-only

このフラグに続くすべての <file> 引数に対して、オブジェクトデータベースにオブジェクトを作成しません。 オブジェクトIDをインデックスに挿入するだけです。

--force-remove

作業ディレクトリにそのようなファイルがまだある場合でも、インデックスからファイルを削除します。 (--remove の指定を含んでいます。)

--replace

デフォルトでは、ファイル path がインデックスに存在する場合、 git update-indexpath/file を追加する試みを拒否します。 同様に、ファイル path/file が存在する場合、ファイル path を追加することはできません。 --replace フラグを使用すると、競合する既存のエントリが警告メッセージとともに自動的に削除されて、エントリが追加されます。

--stdin

Instead of taking a list of paths from the command line, read a list of paths from the standard input. Paths are separated by LF (i.e. one path per line) by default.

--verbose

Report what is being added and removed from the index.

--index-version <n>

Write the resulting index out in the named on-disk format version. Supported versions are 2, 3, and 4. The current default version is 2 or 3, depending on whether extra features are used, such as git add -N. With --verbose, also report the version the index file uses before and after this command.

Version 4 performs a simple pathname compression that reduces index size by 30%-50% on large repositories, which results in faster load time. Git supports it since version 1.8.0, released in October 2012, and support for it was added to libgit2 in 2016 and to JGit in 2020. Older versions of this manual page called it "relatively young", but it should be considered mature technology these days.

--show-index-version

Report the index format version used by the on-disk index file. See --index-version above.

-z

これは --stdin または --index-info でのみ意味があります。 パスは、LFではなくNUL文字で区切られます。

--split-index
--no-split-index

分割インデックスモードを有効または無効にします。 分割インデックスモードがすでに有効になっていて、 --split-index が再度指定された場合、 $GIT_DIR/index のすべての変更が共有インデックスファイルに押し返されます。

これらのオプションは、構成変数 core.splitIndex の値が何であれ有効になります(git-config(1) 参照)。 しかし、構成変数 core.splitIndex の設定値に反する変更を行うと警告が表示されます。なぜなら、次回インデックスを読み込むときには構成変数 core.splitIndex の設定値が有効になり、オプションの意図した効果がなくなってしまうからです。

--untracked-cache
--no-untracked-cache

追跡されていないモノのキャッシュ機能を有効または無効にします。 有効にする前には --test-untracked-cache の使用をお願いします。

これらのオプションは、 core.untrackedCache 構成変数の値に関係なく有効になります(git-config(1) 参照)。 ただし、 core.untrackedCache 構成変数設定値に反する変更を行うと警告が表示されます。これは、インデックスを次に読み込むときには core.untrackedCache 構成変数設定値が有効になり、このオプションが意図したとおりの効果を得られなくなってしまうからです。

--test-untracked-cache

追跡されていないモノのキャッシュ(untracked cache)を使用できることを確認するために、作業ディレクトリでのみテストを実行します。 本当に使用したい場合は、後で --untracked-cache または --force-untracked-cache または core.untrackedCache 構成変数を使用して、追跡されていないモノのキャッシュ(untracked cache)を手動で有効にする必要があります。 テストが失敗した場合、exitコードは1であり、必要に応じて機能しないことを説明するメッセージが表示されます。それ以外の場合、exitコードは0であり、OKと出力されます。

--force-untracked-cache

--untracked-cache と同一です。 --untracked-cache--test-untracked-cache を意味するために使用されていた古いバージョンのGitとの下位互換性のために提供されていますが、このオプションは無条件に拡張を有効にします。

--fsmonitor
--no-fsmonitor

ファイルシステムモニター機能を有効または無効にします。 これらのオプションは、設定変数 core.fsmonitor の値が何であっても有効になります((git-config(1) 参照)。 しかし、設定変数 core.fsmonitor の設定値と異なる変更を行うと警告が表示されます。インデックスを次に読み込む際には設定変数 core.fsmonitor の設定値が有効となり、オプションの意図した効果がなくなってしまうからです。

--

これ以降の引数をオプションとして解釈しないでください。

<file>

作用するファイル。 注意: . で始まるファイルは破棄されます。 これには、 ./filedir/./file が含まれます。 これがあなたの求めるものでない場合は、よりクリーンな名前を使用してください。 / で終わるディレクトリと // で終わるパスにも同じことが当てはまります。

USING --refresh

--refresh は、新しいsha1ファイルを計算したり、また、モード/コンテンツ の変更についてインデックスを最新の状態にしたりしません。 ただし、ファイルの統計情報をインデックスと「再照合」(re-match)することで、変更されていないが統計エントリが古くなっているファイルのインデックスを更新できます。

たとえば、あなたが「git read-tree」を実行した後にこれを実行して、統計インデックスの詳細を適切なファイルにリンクすることができます。

USING --cacheinfo OR --info-only

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

path に mode と sha1 を持つファイルがあるように見せかけるには、以下のようにします:

$ git update-index --add --cacheinfo <mode>,<sha1>,<path>

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

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

USING --index-info

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

  1. mode SP type SP sha1 TAB path

    この形式は、 git ls-tree 出力をインデックスに詰め込むためのものです。

  2. mode SP sha1 SP stage TAB path

    この形式は、より高次のステージをインデックスファイルに配置するためのものであり、 git ls-files --stage の出力と一致します。

  3. mode SP sha1 TAB path

    この形式はGitコマンドでは生成されなくなりましたが、 update-index --index-info では引き続きサポートされます。

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

たとえば、以下のインデックスから始めます:

$ git ls-files -s
100644 8a1218a1024a212bb3db30becd860315f9f3ac52 0       frotz

あなたは以下の入力を --index-info にフィードできます:

$ git update-index --index-info
0 0000000000000000000000000000000000000000      frotz
100644 8a1218a1024a212bb3db30becd860315f9f3ac52 1       frotz
100755 8a1218a1024a212bb3db30becd860315f9f3ac52 2       frotz

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

$ git ls-files -s
100644 8a1218a1024a212bb3db30becd860315f9f3ac52 1       frotz
100755 8a1218a1024a212bb3db30becd860315f9f3ac52 2       frotz

「assume unchanged」(無変更と仮定する)ビットの使用

Gitの多くの操作は、効率的な lstat(2) 実装をファイルシステムに依存しているため、作業ツリーファイルの st_mtime 情報を低コストでチェックして、ファイルの内容がインデックスファイルに記録されているバージョンから変更されているかどうかを確認できます。 残念ながら、一部のファイルシステムには非効率的な lstat(2) があります。 ファイルシステムがそれらの1つである場合は、変更していないパスに「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 構成変数を調べます。 core.ignorestat` 構成変数が true の場合、 git update-index paths... で更新されたパスと、インデックスと作業ツリーの両方を更新する他のGitコマンド(例: git apply --indexgit checkout-index -ugit read-tree -u)で更新されたパスは、自動的に「変更されていないと見なす」とマークされます。 注意: git update-index --refresh が、作業ツリーファイルとインデックスが一致することを検出した場合、「assume unchanged」ビットは設定されないことに注意してください(あなたがそれらに「assume unchanged」マークを付けたい場合は、 git update-index --really-refresh を使用してください)。

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

EXAMPLES

すでにチェックアウトされているファイルのみをupdateおよびrefreshするには:

$ git checkout-index -n -f -a && git update-index --ignore-missing --refresh
core.ignorestat が設定された非効率的なファイルシステム上で…
$ git update-index --really-refresh              <1>
$ git update-index --no-assume-unchanged foo.c   <2>
$ git diff --name-only                           <3>
$ edit foo.c
$ git diff --name-only                           <4>
M foo.c
$ git update-index foo.c                         <5>
$ git diff --name-only                           <6>
$ edit foo.c
$ git diff --name-only                           <7>
$ git update-index --no-assume-unchanged foo.c   <8>
$ git diff --name-only                           <9>
M foo.c
  1. lstat(2) に、インデックスに一致するパスに「assume unchanged」(無変更仮定)ビットをセットするように強制します。

  2. 編集するパスをマークします。

  3. これは lstat(2) を実行し、インデックスがパスに一致することを検出します。

  4. これは lstat(2) を実行し、インデックスがパスと「一致しない」ことを検出します。

  5. 新しいバージョンをインデックスに登録すると、「assume unchanged」(無変更仮定)ビットがセットされます。

  6. そしてそれは無変更と仮定されています(assumed unchanged)。

  7. それを編集した後でもです。

  8. あなたは事後に、変更について伝える事ができます。

  9. いまや、 lstat(2) をチェックして、変更されていることがわかります。

SKIP-WORKTREE BIT

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

注意: すべての git コマンドがこのビットに注意を払うわけではなく、部分的にしかサポートしていないものもあります。

update-index フラグと skip-worktree ビットに関連する read-tree 機能は、 git-sparse-checkout(1) コマンド導入以前のものです。 git-sparse-checkout(1) コマンド導入により、skip-worktree ビットを構成および処理するはるかに簡単な方法が提供されます。 リポジトリ内のファイルのサブセットのみを処理するように作業ツリーを縮小したい場合は、 低レベルの update-index や read-tree プリミティブに優先して、 git-sparse-checkout(1) の使用を強くお勧めします。

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

このビットは、assume-unchange ビットに似ていますが、その目的は異なります。 変更されていないと仮定するビットは、 ファイルを作業ツリーに残しますが、 Git に変更のチェックを省略させ、 ファイルが変更されていないと推定するためのものです(ただし、 ファイルが変更されたと明記せずに判断できる場合は、 その変更を記録するのは自由にできます)。 skip-worktree は Git にファイルの不在を無視するように指示し、 通常は作業ディレクトリの大部分を更新するコマンド(例: checkout や`switch` や pull など)で可能な場合はファイルを更新しないようにし、その不在がコミットに記録されないようにします。 注意: (git sparse-checkout または core.sparseCheckout を true に設定してセットアップする)スパース・チェックアウトでは、 ファイルがインデックスで skip-worktree としてマークされているが、作業ツリー内で見つかった場合、 Git はそのファイルの skip-worktree ビットをクリアすることに注意してください。

SPLIT INDEX

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

このモードでは、インデックスは $GIT_DIR/index と $GIT_DIR/sharedindex.<SHA-1> の2つのファイルに分割されます。 変更は分割インデックスである $GIT_DIR/index に蓄積されますが、共有インデックス(shared index)ファイルにはすべてのインデックスエントリが含まれ、変更されません。

分割インデックスのエントリ数が splitIndex.maxPercentChange 構成変数で指定されたレベルに達すると、分割インデックスのすべての変更が共有インデックスファイルに押し戻されます(git-config(1) 参照)。

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

まだ使用されている共有インデックスファイルの削除を回避するために、共有インデックスファイルに基づく新しい分割インデックスが、作成または読み取られるたびに、その変更時刻が現在の時刻に更新されます。

UNTRACKED CACHE

このキャッシュは、 git status などの追跡されていないファイルの判別を伴うコマンドを高速化することを目的としています。

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

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

この機能を有効(または無効)にする場合は、 各リポジトリで --untracked-cache オプションを git update-index に使用するよりも、 core.untrackedCache 構成変数(git-config(1) 参照)を使用する方が簡単です。 特に、使用しているすべてのリポジトリに対してそうしたい場合は、あなたの $HOME/.gitconfigcore.untrackedCache 構成変数を true(または false)と一度セットするだけですべてのリポジトリでその機能を使えるため、簡単です。

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

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

$ git -c core.untrackedCache=false status

このバグは、追跡されていないモノのキャッシュ(untracked cache)の内部構造に関して、ディレクトリをファイルに置き換えるシンボリックリンク以外のケースにも影響を与えることが示されていますが、これにより誤った「git status」出力が発生したケースは報告されていません。

2.17より前のバージョンのgitによって書き込まれた既存のインデックスが、もう存在しないディレクトリを参照し、「could not open directory」(ディレクトリを開けませんでした)という警告が「git status」に出力される可能性があります。 これらは、以前は黙って破棄されていた既存の問題に対する新しい警告です。

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

FILE SYSTEM MONITOR

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

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

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

この機能を有効(または無効)にする場合は、 各リポジトリの git update-index--fsmonitor オプションを付けるよりも、 core.fsmonitor 構成変数(git-config(1) 参照)を使用する方が簡単です。 特に、すべてのリポジトリで同じことをしたい場合は、あなたの $HOME/.gitconfigcore.fsmonitor 構成変数を一度設定するだけですべてのリポジトリでそれが適用されるので、使い勝手はよいでしょう。

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

CONFIGURATION

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

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

このコマンドは、 core.ignorestat 構成変数を調べます。 上記「Using "assume unchanged" bit」セクションを参照してください。

このコマンドは、 core.trustctime 構成変数も調べます。 iノードの変更時刻がGitの外部で定期的に変更される場合に便利です(ファイルシステムクローラーとバックアップシステムは、処理されたファイルのマーキングにctimeを使用します)(git-config(1) 参照)。

追跡されていないモノのキャッシュ(untracked cache)拡張は、 core.untrackedCache 構成変数によって有効にできます(git-config(1) 参照)。

NOTES

ユーザーは、追跡されるファイルへの変更を無視するようにGitに指示するために、assume-unchangedビット と skip-worktreeビット を使用しようと試みることがよくありますが、 Gitは特定の操作を実行するときに、インデックスに対して作業ツリーファイルをチェックする可能性があるため、これは期待どおりに機能しません。 一般に、Gitは追跡されたファイルへの変更を無視する方法を提供しないため、別の解決策をお勧めします。

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

SEE ALSO

GIT

Part of the git(1) suite