我們有數百個存盤庫，并定期從上游接收補丁。作業應用這些補丁git apply --check <patch>。如果沒有錯誤，則應用補丁git apply <patch>并提交更改。如果有任何錯誤，補丁會被標記為conflict。然后將錯誤和沖突的補丁交付給我們的存盤庫維護人員。它們用于git apply --reject <patch>應用補丁并解決沖突。
以我之前的理解，git apply --reject是可靠的。然而，一位維護者報告說補丁的應用方式完全錯誤。一些新行被插入到一個意外函式中的塊中，這恰好具有相同的背景關系。還有一些其他錯誤的塊。
比如補丁中的chunk是
@@ -1757,9 1757,9 @@ def FunctionAAA()
print('hi')
}
print('hello world')
print('good day')
return True
但是在應用的檔案中，塊是
@@ -1927,9 1997,9 @@ def FunctionBBB() ---> in another function
print('hi')
}
print('hello world')
print('good day')
return True
維護者很可能沒有注意到錯位的行，這會導致構建錯誤甚至更糟的隱藏錯誤。我讓維護者嘗試git apply --3way <patch>并按預期應用補丁，盡管仍然存在沖突。
我的想法git apply --reject和git apply --3way行為不同，因為他們使用不同的演算法。從結果來看，我想我們需要采用git apply --3way. 但我也擔心--3way在某些情況下可能會意外地起作用。
為什么git apply --reject以看似錯誤的方式作業而不是將塊視為沖突？在我們的情況下哪個更好？有沒有更好的解決方案來應用補丁？謝謝。
git version 2.31.1
ubuntu 4.15.0-76-generic
uj5u.com熱心網友回復：
TL;DR：--3way如果可能的話，你確實想要。
這里有一些歷史。該git apply命令最初至少部分是對拉里沃爾歷史patch命令的復制，或多或少。此補丁命令始終在--reject模式下運行（請參閱檔案：(POSIX) , (non-POSIX)）。在這種模式下運行時，它永遠不會進行三路合并。
另一方面，補丁有缺陷：應用于背景關系匹配的模糊因子允許插入指示的更改，即使背景關系實際上不匹配。（Git的apply沒有絨毛。）背景關系匹配可以去錯了，因為它顯然是在你的情況一樣，找到一個類似的尋找功能，但不正確的函式。三路合并通過三個輸入避免了這些問題：
- 該合并基礎，或共同的起點;
- 您的檔案版本；和
- 他們的檔案版本。
Git 可以使用Index:Git 補丁中的行構建其中兩個版本，其中包含檔案基本版本的 blob 哈希 ID。Git 只是使用哈希 ID 在存盤庫中查找正確的 blob 物件。如果該物件存在，那就是他們在 diff 中作為“之前”副本的檔案，因此 Git 可以提取該物件，完全按照其出現的方式應用補丁，并生成該檔案的“他們的”版本。Git 現在可以對三個檔案進行正常的三向合并。
該--3way選項在兩種情況下失敗：
如果沒有
Index:給出合并基礎版本的行，則 Git 無法知道檔案的哪個副本是背景關系差異中的“之前”版本。如果存在有效的索引行，但您的存盤庫中沒有該物件，則 Git 無法構建檔案的基礎及其副本。
在這些情況下，唯一可用的選項是后備：嘗試找到正確的背景關系（并希望很多并--reject在需要時使用）。
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/371729.html