什么是“git diff --patience”？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/4045017/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
What is `git diff --patience` for?
提问by Gabe Moothart
How does the patience algorithm differ from the default git diffalgorithm, and when would I want to use it?
耐心算法与默认git diff算法有何不同，我想在什么时候使用它？
采纳答案by Mark Rushakoff
You can read a post from Bram Cohen, the author of the patience diff algorithm, but I found this blog postto summarize the patience diff algorithm very well:
你可以阅读耐心差异算法的作者Bram Cohen的一篇文章，但我发现这篇博文很好地总结了耐心差异算法：
Patience Diff, instead, focuses its energy on the low-frequency high-content lines which serve as markers or signatures of important content in the text. It is still an LCS-based diff at its core, but with an important difference, as it only considers the longest common subsequence of the signature lines:
Find all lines which occur exactly once on both sides, then do longest common subsequence on those lines, matching them up.
相反，Patience Diff 将精力集中在低频高内容行上，这些行用作文本中重要内容的标记或签名。它的核心仍然是基于 LCS 的差异，但有一个重要的区别，因为它只考虑签名行的最长公共子序列：
找出两边恰好出现一次的所有行，然后在这些行上做最长公共子序列，将它们匹配起来。
When should you usepatience diff? According to Bram, patience diff is good for this situation:
什么时候应该使用耐心差异？根据布拉姆的说法，耐心差异对这种情况有好处：
The really bad cases are ones where two versions have diverged dramatically and the developer isn't being careful to keep patch sizes under control. Under those circumstances a diff algorithm can occasionally become 'misaligned' in that it matches long sections of curly brackets together, but it winds up correlating the curly brackets of functions in one version with the curly brackets of the next later function in the other version. This situation is very ugly, and can result in a totally unusable conflict file in the situation where you need such things to be presented coherently the most.
真正糟糕的情况是两个版本的差异很大，并且开发人员不小心控制补丁大小。在这种情况下，diff 算法有时会变得“未对齐”，因为它将长部分的大括号匹配在一起，但它最终将一个版本中函数的大括号与另一个版本中下一个函数的大括号相关联。这种情况非常难看，在最需要连贯地呈现此类内容的情况下，可能会导致完全无法使用的冲突文件。
回答by robinst
You can also use it for merges (worked really well here for some XML conflicts):
您还可以将它用于合并（对于一些 XML 冲突在这里工作得非常好）：
git merge --strategy-option=patience ...
回答by Wilfred Hughes
The patience diff algorithm is a slower diff algorithm that shows better results in some cases.
耐心差异算法是一种较慢的差异算法，在某些情况下显示出更好的结果。
Suppose you have the following file checked in to git:
假设您已将以下文件签入到 git：
.foo1 {
margin: 0;
}
.bar {
margin: 0;
}
Now we reorder the sections and add a new line:
现在我们重新排序这些部分并添加一个新行：
.bar {
margin: 0;
}
.foo1 {
margin: 0;
color: green;
}
The default diff algorithm claims that the section headings have changed:
默认 diff 算法声称章节标题已更改：
$ git diff --diff-algorithm=myers
diff --git a/example.css b/example.css
index 7f1bd1e..6a64c6f 100755
--- a/example.css
+++ b/example.css
@@ -1,7 +1,8 @@
-.foo1 {
+.bar {
margin: 0;
}
-.bar {
+.foo1 {
margin: 0;
+ color: green;
}
Whereas patience diff shows a result that is arguably more intuitive:
而耐心差异显示的结果可以说是更直观：
$ git diff --diff-algorithm=patience
diff --git a/example.css b/example.css
index 7f1bd1e..6a64c6f 100755
--- a/example.css
+++ b/example.css
@@ -1,7 +1,8 @@
-.foo1 {
- margin: 0;
-}
-
.bar {
margin: 0;
}
+
+.foo1 {
+ margin: 0;
+ color: green;
+}
There's a good discussion of subjective diff quality here, and git 2.11 is exploring diff heuristics further.
这里对主观差异质量进行了很好的讨论，而git 2.11 正在进一步探索差异启发式。
Note that the patience diff algorithm still has some known pathological cases.
请注意，耐心差异算法仍然有一些已知的病理情况。
