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 是一種更強大的機制，可讓您從標準輸入饋送多個條目定義，並且專為腳本設計。它可以採用三種格式的輸入

若要將較高階段的條目放入索引中，應先透過饋送路徑的模式 = 0 條目來移除路徑，然後再以第三種格式饋送必要的輸入行。

例如，從這個索引開始

您可以將下列輸入饋送給 --index-info

輸入的第一行饋送 0 作為模式以移除路徑；只要格式正確，SHA-1 並不重要。然後，第二行和第三行會饋送該路徑的階段 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）。

有時使用者會將假設未變更的位元與跳過工作樹位元混淆。請參閱下方「跳過工作樹位元」區段的最後一段，以取得差異說明。

若要僅更新和重新整理已簽出的檔案

跳過工作樹位元可以用一句（長）句子定義：告知 Git 在合理的情況下避免將檔案寫入工作目錄，並且當檔案不存在於工作目錄中時，將其視為未變更。

請注意，並非所有 Git 命令都會注意此位元，而且有些命令僅部分支援它。

與跳過工作樹位元相關的 update-index 旗標和 read-tree 功能早於 git-sparse-checkout[1] 命令的引入，後者提供了一種更簡單的方式來組態和處理跳過工作樹位元。如果您想要將工作樹縮減為僅處理儲存庫中的檔案子集，我們強烈建議您使用 git-sparse-checkout[1]，而不是底層的 update-index 和 read-tree 基本功能。

跳過工作樹位元的主要目的是啟用稀疏簽出，也就是說，工作目錄中僅存在路徑的子集。設定跳過工作樹位元時，Git 命令（例如 switch、pull、merge）會避免寫入這些檔案。但是，這些命令有時仍然會在重要情況下寫入這些檔案，例如合併或變基期間發生衝突。Git 命令也會避免將缺少這些檔案視為有意的刪除。例如，git add -u 不會為這些檔案暫存刪除，而 git commit -a 也不會建立刪除這些檔案的提交。

雖然此位元看起來與假設未變更的位元類似，但其目標不同。假設未變更的位元是為了將檔案保留在工作樹中，但讓 Git 省略檢查其變更，並假設檔案未變更（不過，如果可以在不使用 stat 的情況下確定檔案已變更，則可以自由記錄變更）。跳過工作樹會告知 Git 忽略缺少檔案、盡可能避免使用通常更新大部分工作目錄的命令（例如 checkout、switch、pull 等）來更新它，並且不要在提交中記錄其缺失。請注意，在稀疏簽出中（由 git sparse-checkout 設定，或將 core.sparseCheckout 組態為 true 設定），如果檔案在索引中標記為跳過工作樹，但在工作樹中找到，Git 會清除該檔案的跳過工作樹位元。

此模式專為具有非常大索引的儲存庫設計，旨在減少重複寫入這些索引所需的時間。

在此模式下，索引會分割成兩個檔案，$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 中隱含執行該測試，但現在已不再如此。

如果您想要啟用（或停用）此功能，使用 core.untrackedCache 組態變數（請參閱 git-config[1]）會比在每個儲存庫中使用 git update-index 的 --untracked-cache 選項更容易，特別是當您想要在您使用的所有儲存庫中執行此操作時，因為您可以在 $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() 來查找已修改的檔案。

當與未追蹤快取結合使用時，它可以通過避免掃描整個工作目錄以查找新檔案的成本來進一步提高效能。

如果您想要啟用（或停用）此功能，使用 core.fsmonitor 組態變數（請參閱 git-config[1]）會比在每個儲存庫中使用 git update-index 的 --fsmonitor 選項更容易，特別是當您想要在您使用的所有儲存庫中執行此操作時，因為您可以在 $HOME/.gitconfig 中將組態變數設定一次，即可影響您所接觸的所有儲存庫。

當 core.fsmonitor 組態變數變更時，檔案系統監控器會在下次指令讀取索引時新增至索引或從索引中移除。當使用 --[no-]fsmonitor 時，檔案系統監控器會立即新增至索引或從索引中移除。

此指令會遵守 core.filemode 組態變數。如果您的儲存庫位於執行位元不可靠的檔案系統上，則應將此設定為 *false*（請參閱 git-config[1]）。如果索引中記錄的檔案模式與檔案系統上的檔案模式僅在執行位元上有所不同，這會導致指令忽略它們之間的差異。在這樣不幸的檔案系統上，您可能需要使用 *git update-index --chmod= *。

同樣地，如果 core.symlinks 組態變數設定為 *false*（請參閱 git-config[1]），符號連結會以純文字檔案的形式檢出，並且此指令不會將記錄的檔案模式從符號連結修改為常規檔案。

此指令會查看 core.ignorestat 組態變數。請參閱上面的「使用“假設未變更”位元」章節。

此指令也會查看 core.trustctime 組態變數。當節點變更時間經常被 Git 外部的東西修改時（檔案系統爬蟲和備份系統使用 ctime 來標記已處理的檔案），這會很有用（請參閱 git-config[1]）。

未追蹤快取擴展可以由 core.untrackedCache 組態變數啟用（請參閱 git-config[1]）。

使用者經常嘗試使用 assume-unchanged 和 skip-worktree 位元來告訴 Git 忽略對已追蹤檔案的變更。這無法按預期工作，因為 Git 在執行某些操作時仍可能檢查工作樹檔案是否與索引一致。一般而言，Git 不提供忽略對已追蹤檔案變更的方法，因此建議使用替代解決方案。

例如，如果您想要變更的檔案是某種組態檔，儲存庫可以包含一個範例組態檔，然後可以將其複製到忽略的名稱中並進行修改。儲存庫甚至可以包含一個腳本，將範例檔案視為範本，自動修改和複製它。

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

屬於 git[1] 套件的一部分