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）。

有時使用者會混淆 assume-unchanged 位和 skip-worktree 位。請參閱下面的“Skip-worktree 位”部分的最後一段，瞭解它們之間的區別。

僅更新和重新整理已簽出檔案的操作

Skip-worktree 位可以用一個（長）句子來定義：告訴 git 在合理可能的情況下避免將檔案寫入工作目錄，並在檔案不在工作目錄中時將其視為未更改。

請注意，並非所有 git 命令都會關注此位，有些命令僅部分支援它。

update-index 標誌和與 skip-worktree 位相關的 read-tree 功能在 git-sparse-checkout[1] 命令引入之前就已存在，該命令提供了一種更簡便的方法來配置和處理 skip-worktree 位。如果您想將工作目錄限制為只處理儲存庫中的部分檔案，我們強烈建議優先使用 git-sparse-checkout[1] 而不是底層的 update-index 和 read-tree 原語。

skip-worktree 位的主要目的是啟用稀疏簽出，即擁有隻有部分路徑存在的工作目錄。當設定 skip-worktree 位時，Git 命令（例如 switch、pull、merge）將避免寫入這些檔案。但是，在發生重要情況（例如合併或 rebase 期間的衝突）時，這些命令有時仍會寫入這些檔案。Git 命令還將避免將這些檔案的缺失視為有意刪除；例如 git add -u 不會為這些檔案暫存刪除，git commit -a 也不會透過提交來刪除它們。

儘管此位看起來與 assume-unchanged 位相似，但其目標不同。assume-unchanged 位用於保留工作樹中的檔案，但讓 Git 忽略對其的更改檢查，並假定檔案未被更改（儘管如果 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.<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 選項測試檔案系統是否支援此功能。在較舊版本的 Git 中，--untracked-cache 選項會隱式執行此測試，但現在已不再如此。

如果您想啟用（或停用）此功能，使用 core.untrackedCache 配置變數（請參閱 git-config[1]）比在每個儲存庫中使用 git update-index 的 --untracked-cache 選項更容易，特別是如果您想跨所有使用的儲存庫執行此操作，因為您可以將配置變數設定為 true（或 false）在您的 $HOME/.gitconfig 中只需一次，它就會影響您接觸到的所有儲存庫。

當 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”時列印大量“無法開啟目錄”警告。這些是先前被靜默忽略的現有問題的新的警告。

與上述錯誤一樣，解決方案是執行一次“git status”執行，並將 core.untrackedCache 設定為 false，以清除殘留的壞資料。

此功能旨在加快具有大型工作目錄的儲存庫的 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 配置變數。當 inode 更改時間經常被 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] 套件的一部分