git-update-index(1)

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>]
             [--verbose]
             [--] [<file>…]

DESCRIPTION

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

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

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

OPTIONS

--add: 指定のファイルがまだインデックスにない場合は、追加されます。デフォルトの動作では、新規ファイルは無視されます。
--remove: 指定のファイルがインデックスに含まれているが欠落している場合、そのファイルは削除されます。デフォルトの動作では、削除済のファイルは無視されます。
--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: このフラグを指定すると、パスに記録されているオブジェクト名は更新されません。代わりに、このオプションは、パスの「assume unchanged」(無変更仮定)ビットを設定(1)/設定解除(0) します。「assume unchanged」ビットがオンの場合、ユーザーはファイルを変更しないことを約束し、作業ツリーファイルがインデックスに記録されているものと一致するとGitに想定させます。作業ツリーファイルを変更する場合は、Gitに通知するビットを設定解除する必要があります。これは、 lstat(2) システムコールが非常に遅いファイルシステム(cifsなど)で大きなプロジェクトを操作する場合に役立つことがあります。

インデックス内のこのファイルを変更する必要がある場合、例えばコミットにマージするとき、Gitは(正常に)失敗します。したがって、追跡されていないと仮定されるファイルがアップストリームで変更された場合、あなたは状況を手動で処理する必要があります。
--really-refresh: --refresh と同様ですが、「assume unchanged」設定に関係なく、統計情報を無条件にチェックします。
--[no-]skip-worktree: これらのフラグのいずれかが指定されている場合、パスに記録されているオブジェクト名は更新されません。代わりに、これらのオプションは、パスの「skip-worktree」ビットを設定および設定解除します。詳細については、下記「Skip-worktree bit」のセクションを参照してください。
--[no-]ignore-skip-worktree-entries: --remove オプションが指定されている場合でも、 skip-worktree (別名「インデックスのみ」) エントリを削除しないでください。
--[no-]fsmonitor-valid: これらのフラグのいずれかが指定されている場合、パスに記録されているオブジェクト名は更新されません。代わりに、これらのオプションは、パスの「fsmonitor valid」ビットを設定および設定解除します。詳細については、下記「File System Monitor」のセクションを参照してください。
-g
--again: インデックスエントリが HEAD コミットとは異なるパスで git update-index 自体を実行します。
--unresolve: 誤ってクリアされた場合、マージ処理中のファイルの「unmerged」(マージされていない)または「needs updating」(更新が必要)状態を復元します。
--info-only: このフラグに続くすべての <file> 引数に対して、オブジェクトデータベースにオブジェクトを作成しません。オブジェクトIDをインデックスに挿入するだけです。
--force-remove: 作業ディレクトリにそのようなファイルがまだある場合でも、インデックスからファイルを削除します。 (--remove の指定を含んでいます。)
--replace: デフォルトでは、ファイル path がインデックスに存在する場合、 git update-index は path/file を追加する試みを拒否します。同様に、ファイル path/file が存在する場合、ファイル path を追加することはできません。 --replace フラグを使用すると、競合する既存のエントリが警告メッセージとともに自動的に削除されて、エントリが追加されます。
--stdin: コマンドラインからパスのリストを取得する代わりに、標準入力からパスのリストを読み取ります。デフォルトでは、パスはLFで区切られます(つまり、1行に1つのパス)。
--verbose: インデックスに追加・削除されているものを報告します。
--index-version <n>: 結果のインデックスを、指定のディスク上のフォーマットバージョン(on-disk format version)で書き出します。サポートされているバージョンは 2 と 3 と 4 です。現在のデフォルトバージョンは、 git add -N などの追加機能が使用されているかどうかに応じて、 2 または 3 です。

バージョン4は、単純なパス名圧縮を実行し、大規模なリポジトリでインデックスサイズを30%〜50%削減します。これにより、読み込み時間が短縮されます。バージョン4は比較的若いです(2012年10月の1.8.0で最初にリリースされました)。 JGitやlibgit2などの他のGit実装は、まだサポートしていない可能性があります。
-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>: 作用するファイル。注意: . で始まるファイルは破棄されます。これには、 ./file と dir/./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つの形式の入力を受け取ることができます:

mode SP type SP sha1 TAB path

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

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

lstat(2) に、インデックスに一致するパスに「assume unchanged」(無変更仮定)ビットをセットするように強制します。
編集するパスをマークします。
これは lstat(2) を実行し、インデックスがパスに一致することを検出します。
これは lstat(2) を実行し、インデックスがパスと「一致しない」ことを検出します。
新しいバージョンをインデックスに登録すると、「assume unchanged」(無変更仮定)ビットがセットされます。
そしてそれは無変更と仮定されています(assumed unchanged)。
それを編集した後でもです。
あなたは事後に、変更について伝える事ができます。
いまや、 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 ビットが設定されている場合、 (switch や pull や merge のような) 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/.gitconfig で core.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/.gitconfig で core.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は追跡されたファイルへの変更を無視する方法を提供しないため、別の解決策をお勧めします。

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

GIT

Part of the git(1) suite

git-update-index(1) Manual Page

NAME

SYNOPSIS

DESCRIPTION

OPTIONS

USING `--refresh`

USING `--cacheinfo` OR `--info-only`

USING `--index-info`

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

EXAMPLES

SKIP-WORKTREE BIT

SPLIT INDEX

UNTRACKED CACHE

FILE SYSTEM MONITOR

CONFIGURATION

NOTES

SEE ALSO

GIT

git-update-index(1) Manual Page

NAME

SYNOPSIS

DESCRIPTION

OPTIONS

USING --refresh

USING --cacheinfo OR --info-only

USING --index-info

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

EXAMPLES

SKIP-WORKTREE BIT

SPLIT INDEX

UNTRACKED CACHE

FILE SYSTEM MONITOR

CONFIGURATION

NOTES

SEE ALSO

GIT

USING `--refresh`

USING `--cacheinfo` OR `--info-only`

USING `--index-info`