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

Question

当我尝试比较通常出现在 html/css 中的具有相同结构的 block 时，就会出现问题。例子: Initial commit

现在让我们将新参数添加到“someblock”和新类“someotherblock”。 result

预期结果:

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

有没有办法让 git 理解更改的“逻辑”？

Answer 1

重要的是要认识到，Git 不会，而且确实不能，向您显示确切您所做的事情。 (也许你先添加了大括号，然后添加了内容，按照这个顺序，在这种情况下向你展示你做了什么它必须说“首先添加两个大括号，然后在它们之间添加内容".) 相反，Git 只是生成一组最小的¹ 指令，告诉计算机 如何将“之前存在的”更改为“现在应该存在的”。

Git 程序员试图让“计算机可以理解”的指令对人类也有些敏感，但答案是:

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

是“否”。

patience diff(参见 Gira's answer)在某些情况下会有所帮助，尤其是 Git 在仅由左大括号或右大括号等组成的行上进行同步的情况。

Git 2.9 添加了所谓的“compaction heuristic”(相当轻松地描述了 here )，但它需要在更改区域上方有一个空行。那个短语，“a blank line above”，意味着a blank line，above:压缩启发式不相信文件的顶部就足够了(尽管在我看来它应该相信这一点)。压缩启发式算法产生了更大的不同，尽管对我来说，扭曲源代码只是为了让 VCS 显示更好的差异的想法是......至少令人讨厌。

---

¹“最小”是指尽可能少的“删除 X”和“添加 Y”指令。 Git 不考虑 X 和 Y 的长度，它们通常是行，尽管 Git 也有面向单词的差异。关系——Git 可以说“在这里删除四行，在那里添加四行”，然后上下移动四行，由于所使用的算法而被打破以支持“最远的”，这就是为什么压缩试探法只尝试上移。