git-read-tree · Git 中文參考

# git-read-tree > 原文： [https://git-scm.com/docs/git-read-tree](https://git-scm.com/docs/git-read-tree) ## 名稱 git-read-tree - 將樹信息讀入索引 ## 概要 ``` git read-tree [[-m [--trivial] [--aggressive] | --reset | --prefix=<prefix>] [-u [--exclude-per-directory=<gitignore>] | -i]] [--index-output=<file>] [--no-sparse-checkout] (--empty | <tree-ish1> [<tree-ish2> [<tree-ish3>]]) ``` ## 描述讀取由< tree-ish>給出的樹信息。進入索引，但實際上并沒有**更新**它“緩存”的任何文件。（參見： [git-checkout-index [1]](https://git-scm.com/docs/git-checkout-index) ）可選地，它可以將樹合并到索引中，使用`-m`標志執行快進（即2路）合并或3路合并。與`-m`一起使用時，`-u`標志會使它還使用合并結果更新工作樹中的文件。普通合并由 _git read-tree_ 本身完成。當 _git read-tree_ 返回時，只有沖突路徑處于未合并狀態。 ## OPTIONS ``` -m ``` 執行合并，而不僅僅是讀取。如果您的索引文件包含未合并的條目，則該命令將拒絕運行，表示您尚未完成之前的合并。 ``` --reset ``` 與-m相同，除了丟棄未合并的條目而不是失敗。 ``` -u ``` 成功合并后，使用合并結果更新工作樹中的文件。 ``` -i ``` 通常，合并需要索引文件以及工作樹中的文件與當前頭部提交保持同步，以免丟失本地更改。此標志禁用對工作樹的檢查，并且在創建與當前工作樹狀態不直接相關的樹的合并到臨時索引文件時使用。 ``` -n ``` ``` --dry-run ``` 檢查命令是否會出錯，而不更新索引或工作樹中的文件是否真實。 ``` -v ``` 顯示檢出文件的進度。 ``` --trivial ``` 限制 _git read-tree_ 的三向合并只有在不需要文件級合并時才會發生，而不是為簡單的情況解析合并并在索引中保留未解決的沖突文件。 ``` --aggressive ``` 通常， _git read-tree_ 的三向合并解決了真正瑣碎案例的合并，并使索引中的其他案例無法解決，因此瓷器可以實現不同的合并策略。此標志使命令在內部解決了幾個案例： * 當一側移除路徑而另一側離開路徑未經修改時。決議是刪除該路徑。 * 當雙方都刪除一條路徑。決議是刪除該路徑。 * 當雙方都添加相同的路徑時。決議是添加該路徑。 ``` --prefix=<prefix> ``` 保留當前索引內容，并在`<prefix>`目錄下讀取指定tree-ish的內容。該命令將拒絕覆蓋原始索引文件中已存在的條目。 ``` --exclude-per-directory=<gitignore> ``` 使用`-u`和`-m`選項運行命令時，合并結果可能需要覆蓋當前分支中未跟蹤的路徑。該命令通常拒絕繼續合并以避免丟失這樣的路徑。然而，這種安全閥有時會妨礙。例如，經常會發生另一個分支添加了一個文件，該文件曾經是分支中生成的文件，當您在運行`make`之后但在運行`make clean`之前嘗試切換到該分支時，安全閥會觸發刪除生成的文件。此選項告訴命令讀取每個目錄的排除文件（通常是 _.gitignore_ ），并允許覆蓋這樣一個未跟蹤但明確忽略的文件。 ``` --index-output=<file> ``` 而不是將結果寫入`$GIT_INDEX_FILE`，而是在命名文件中寫入結果索引。在命令運行時，原始索引文件使用與通常相同的機制鎖定。該文件必須允許從通常索引文件旁邊創建的臨時文件重命名（2）;通常這意味著它需要與索引文件本身位于同一文件系統上，并且您需要對索引文件和索引輸出文件所在目錄的寫入權限。 ``` --[no-]recurse-submodules ``` 使用--recurse-submodules將通過遞歸調用read-tree，根據超級項目中記錄的提交更新所有初始化子模塊的內容，同時將子模塊HEAD設置為在該提交時分離。 ``` --no-sparse-checkout ``` 即使`core.sparseCheckout`為true，也禁用稀疏檢出支持。 ``` --empty ``` 而不是將樹對象讀入索引，只需清空它。 ``` <tree-ish#> ``` 要讀取/合并的樹對象的id。 ## 并構如果指定了`-m`， _git read-tree_ 可以執行3種合并，如果只給出1棵樹，則單個樹合并，2棵樹的快進合并或3路合并如果提供3棵或更多樹。 ### 單樹合并如果僅指定了1個樹，則 _git read-tree_ 的操作就好像用戶沒有指定`-m`，除非原始索引具有給定路徑名的條目，并且路徑的內容匹配在讀取樹時，使用索引中的統計信息。（換句話說，索引的stat（）s優先于合并的樹）。這意味著如果你執行`git read-tree -m <newtree>`后跟`git checkout-index -f -u -a`， _git checkout-index_ 只檢查真正改變的東西。當 _git diff-files_ 在 _git read-tree_ 之后運行時，這用于避免不必要的錯誤命中。 ### 兩棵樹合并通常，這被調用為`git read-tree -m $H $M`，其中$ H是當前存儲庫的頭部提交，而$ M是外部樹的頭部，它只是在$ H之前（即我們處于快速前進狀態））。當指定了兩個樹時，用戶告訴 _git read-tree_ 如下： 1. 當前索引和工作樹是從$ H派生的，但是用戶可能會因為$ H而對其進行局部更改。 2. 用戶希望快進到$ M。在這種情況下，`git read-tree -m $H $M`命令確保沒有因“合并”而丟失本地更改。以下是“結轉”規則，其中“I”表示索引，“clean”表示索引和工作樹重合，“exists”/“nothing”表示指定提交中存在路徑： ``` I H M Result ------------------------------------------------------- 0 nothing nothing nothing (does not happen) 1 nothing nothing exists use M 2 nothing exists nothing remove path from index 3 nothing exists exists, use M if "initial checkout", H == M keep index otherwise exists, fail H != M clean I==H I==M ------------------ 4 yes N/A N/A nothing nothing keep index 5 no N/A N/A nothing nothing keep index 6 yes N/A yes nothing exists keep index 7 no N/A yes nothing exists keep index 8 yes N/A no nothing exists fail 9 no N/A no nothing exists fail 10 yes yes N/A exists nothing remove path from index 11 no yes N/A exists nothing fail 12 yes no N/A exists nothing fail 13 no no N/A exists nothing fail clean (H==M) ------ 14 yes exists exists keep index 15 no exists exists keep index clean I==H I==M (H!=M) ------------------ 16 yes no no exists exists fail 17 no no no exists exists fail 18 yes no yes exists exists keep index 19 no no yes exists exists keep index 20 yes yes no exists exists use M 21 no yes no exists exists fail ``` 在所有“保留索引”的情況下，索引條目保持原始索引文件中的狀態。如果條目不是最新的， _git read-tree_ 在-u標志下操作時保持工作樹中的副本不變。當 _git read-tree_ 的這種形式成功返回時，您可以通過運行`git diff-index --cached $M`來查看您所做的哪些“本地更改”。請注意，這不一定與`git diff-index --cached $H`在這樣的兩個樹合并之前產生的內容相匹配。這是因為案例18和19 ---如果你已經有$ M的變化（例如，你可能通過電子郵件以補丁形式提取），`git diff-index --cached $H`會告訴你這個合并之前的變化，但在兩樹合并后它不會顯示在`git diff-index --cached $M`輸出中。案例3有點棘手，需要解釋。邏輯上，此規則的結果應該是在用戶暫停路徑刪除然后切換到新分支時刪除路徑。然而，這將阻止初始檢出發生，因此僅當索引的內容為空時才修改規則以使用M（新樹）。否則，只要$ H和$ M相同，就會保留路徑的刪除。 ### 三向合并每個“索引”條目都有兩位“階段”狀態。階段0是正常階段，并且是您在任何正常使用中看到的唯一一個。但是，當你用三棵樹做 _git read-tree_ 時，“stage”從1開始。這意味著你可以做到 ``` $ git read-tree -m <tree1> <tree2> <tree3> ``` 你將得到一個包含所有< tree1>的索引“stage1”中的條目，所有< tree2> “stage2”中的條目和所有< tree3> “stage3”中的條目。當執行將另一個分支合并到當前分支時，我們使用公共祖先樹作為< tree1>，將當前分支頭作為< tree2>，將另一個分支頭作為< tree3>。此外， _git read-tree_ 具有特殊情況邏輯，表示：如果您在以下狀態中看到一個在所有方面都匹配的文件，它會“折疊”回“stage0”： * 第2階段和第3階段是相同的;拿一個或另一個（沒有區別 - 我們在第2階段的分支機構和第3階段的分支機構完成了相同的工作） * 階段1和階段2是相同的，階段3是不同的;進入第3階段（我們在第2階段的分支從第1階段的祖先開始沒有做任何事情，而第3階段的分支在第3階段工作） * 階段1和階段3是相同的，階段2是不同的階段2（我們做了什么，而他們什么也沒做） _git write-tree_ 命令拒絕寫一個無意義的樹，如果它看到一個不是第0階段的單個條目，它會抱怨未合并的條目。好吧，這聽起來像是一個完全荒謬的規則集合，但它實際上正是你想要的快速合并。不同的階段代表“結果樹”（階段0，又名“合并”），原始樹（階段1，又名“orig”），以及您嘗試合并的兩棵樹（分別為階段2和階段3）。當您啟動與已填充的索引文件的3向合并時，階段1,2和3的順序（因此三個< tree-ish>命令行參數的順序）非常重要。以下是該算法的工作原理： * 如果一個文件在所有三個樹中以相同的格式存在，它將由 _git read-tree_ 自動折疊為“合并”狀態。 * 具有_任何_差異的文件在三棵樹中將永遠保留為索引中的單獨條目。決定如何刪除非0階段并插入合并版本取決于“瓷器策略”。 * 索引文件使用所有這些信息保存和恢復，因此您可以逐步合并事物，但只要它具有階段1/2/3中的條目（即“未合并條目”），您就無法寫入結果。所以現在合并算法最終變得非常簡單： * 按順序遍歷索引，并忽略階段0的所有條目，因為它們已經完成。 * 如果您找到“stage1”，但沒有匹配的“stage2”或“stage3”，您知道它已從兩個樹中刪除（它只存在于原始樹中），并刪除該條目。 * 如果找到匹配的“stage2”和“stage3”樹，則刪除其中一個，然后將另一個轉換為“stage0”條目。刪除任何匹配的“stage1”條目（如果它也存在）。 ..所有正常的瑣碎規則.. 您通常會使用 _git merge-index_ 與提供的 _git merge-one-file_ 來完成最后一步。該腳本在合并每個路徑和成功合并結束時更新工作樹中的文件。當您使用已填充的索引文件啟動3向合并時，假定它表示工作樹中文件的狀態，甚至可以在索引文件中包含未記錄更改的文件。進一步假設該狀態是從階段2樹“導出”的。如果在原始索引文件中找到與第2階段不匹配的條目，則3向合并將拒絕運行。這樣做是為了防止您丟失正在進行的工作更改，并在不相關的合并提交中混合您的隨機更改。為了說明，假設您從最后提交到存儲庫的內容開始： ``` $ JC=`git rev-parse --verify "HEAD^0"` $ git checkout-index -f -u -a $JC ``` 你做了隨機編輯，沒有運行 _git update-index_ 。然后你注意到你的“上游”樹的尖端已經提升，因為你從他身上拉了下來： ``` $ git fetch git://.... linus $ LT=`git rev-parse FETCH_HEAD` ``` 您的工作樹仍然基于您的HEAD（$ JC），但您已經進行了一些編輯。三向合并確保你沒有添加或修改索引條目，因為$ JC，如果你沒有，那么做正確的事情。所以按以下順序： ``` $ git read-tree -m -u `git merge-base $JC $LT` $JC $LT $ git merge-index git-merge-one-file -a $ echo "Merge with Linus" | \ git commit-tree `git write-tree` -p $JC -p $LT ``` 您將提交的是$ JC和$ LT之間的純合并，而不進行正在進行的工作更改，并且您的工作樹將更新為合并的結果。但是，如果工作樹中的本地更改將被此合并覆蓋， _git read-tree_ 將拒絕運行以防止您的更改丟失。換句話說，不必擔心僅在工作樹中存在的內容。如果項目的一部分中沒有參與合并，則您的更改不會干擾合并，并且保持不變。當他們**做**干擾時，合并甚至沒有開始（ _git read-tree_ 大聲抱怨并且在沒有修改任何內容的情況下失敗）。在這種情況下，您可以繼續執行您正在執行的操作，并且當您的工作樹已準備好（即您已完成正在進行的工作）時，再次嘗試合并。 ## SPARSE CHECKOUT “稀疏檢出”允許稀疏地填充工作目錄。它使用skip-worktree位（參見 [git-update-index [1]](https://git-scm.com/docs/git-update-index) ）告訴Git工作目錄中的文件是否值得查看。 _git read-tree_ 和其他基于合并的命令（ _git merge_ ， _git checkout_ ...）可以幫助維護skip-worktree位圖和工作目錄更新。 `$GIT_DIR/info/sparse-checkout`用于定義跳過工作樹參考位圖。當 _git read-tree_ 需要更新工作目錄時，它會根據此文件重置索引中的skip-worktree位，該文件使用與.gitignore文件相同的語法。如果條目與此文件中的模式匹配，則不會在該條目上設置skip-worktree。否則，將設置skip-worktree。然后它將新的skip-worktree值與前一個值進行比較。如果skip-worktree從set變為unset，它將添加相應的文件。如果它從未設置變為設置，則該文件將被刪除。雖然`$GIT_DIR/info/sparse-checkout`通常用于指定文件所在的文件，但您也可以使用否定模式指定_而不是_中的文件。例如，要刪除文件`unwanted`： ``` /* !unwanted ``` 另一個棘手的問題是，當您不再需要稀疏檢出時，完全重新填充工作目錄。您不能只禁用“稀疏檢出”，因為skip-worktree位仍在索引中，并且您的工作目錄仍然是稀疏填充的。您應該使用`$GIT_DIR/info/sparse-checkout`文件內容重新填充工作目錄，如下所示： ``` /* ``` 然后你可以禁用稀疏檢出。默認情況下， _git read-tree_ 和類似命令中的稀疏檢出支持被禁用。您需要打開`core.sparseCheckout`才能獲得稀疏的結帳支持。 ## 也可以看看 [git-write-tree [1]](https://git-scm.com/docs/git-write-tree) ; [git-ls-files [1]](https://git-scm.com/docs/git-ls-files) ; [gitignore [5]](https://git-scm.com/docs/gitignore) ## GIT 部分 [git [1]](https://git-scm.com/docs/git) 套件