Git diff 错误地解释了我的更改

Question

对我来说，尝试比较 html/css 中通常出现的具有相同结构的块时会出现问题。例子： Initial commit

现在让我们将新参数添加到 "someblock" 和新 class "someotherblock"。 result

预期结果：

 1  1 .someblock
 2  2    height:100%;
    3+   width:100%;
 3  4 }
    5+.someotherblock{
    6+   height:100%;
    7+}

有什么方法可以让 git 理解 "logic" 的变化吗？

Answer 1

您可以尝试打电话进行快速测试：

git diff --patience

或者为所有差异全局设置耐心选项：

git config --global diff.algorithm patience

这将花费更多时间来生成差异，但应该会生成更好的输出。

Answer 2

重要的是要认识到 Git 不会，实际上不能向您确切地 展示您做了什么。（也许你先添加了大括号，然后添加了内容，按照这个顺序，在这种情况下向你展示你做了什么它必须说"first add both braces, then add the contents in between"。）相反， Git 简单地生成一个最小的¹ 指令集，告诉 计算机 如何将 "what was there before" 更改为 "what should be there now".

Git 程序员试图让 "understandable to computer" 指令对人类也有些敏感，但答案是：

Is there any way to make git understand "logic" of the changes?

是"no"。

patience diff（参见）在某些情况下会有所帮助，特别是那些 Git 在仅由开括号或闭括号等组成的行上同步的情况。

Git 2.9 增加了一个所谓的"compaction heuristic"（描述得相当轻松here）但它需要在更改区域上方有一个空行。该短语 "a blank line above" 表示空行，并且以上：压缩启发式不认为文件的顶部足够（虽然在我看来应该相信这一点）。压缩启发式算法有更大的不同，尽管对我来说，扭曲源代码只是为了让 VCS 显示更好的差异的想法是......至少很烦人。

¹"Minimal" 在尽可能少的 "delete X" 和 "add Y" 指令的意义上。 Git 不考虑 X 和 Y 的长度，它们通常是行，尽管 Git 也有面向单词的差异。领带——Git 可以说 "delete four lines here and add four there" 并向上或向下移动四个，由于使用的算法而被打破以支持 "furthest down"，这就是为什么压缩启发式只尝试上移 .

Answer 3

git diff --histogram 就是您要找的。它将以更 human-readable 的方式显示这样的变化。解决了git diff显示括号（花括号）"wrong".

的问题

见

Git diff 错误地解释了我的更改

Git diff incorrectly interprets my changes

git

commit