Question

我经常使用gnu-utils补丁和差异。使用git，我经常这样做：

git diff

通常简单的更改会创建一个大的补丁，因为唯一改变的是，例如，添加一个if / else循环，内部的所有内容都缩进到右边。

查看这样的补丁可能很麻烦，因为只有逐行手动比较才能指示缩进代码中是否有任何实质性更改。我们可能只谈论几行代码，或者几十个（或更多）嵌套代码。（我知道：这样一个假想的大函数最好被分成更小的函数，但这不是重点。）

当代码块中的唯一更改是缩进并让开发人员知道多少时，GNU diff / patch是否能够注意到？

还有其他差异工具以这种方式运行吗？

编辑：好的，有--ignore-space-change但是我们处于两种情况：或者我们有一个人类更可读的补丁，或者我们有一个完整的补丁，机器会知道如何阅读。难道我们不能拥有更好的两个世界中更好的差异工具，它可以显示人类空间的变化，同时允许机器完全应用补丁吗？

Answer 1

使用GNU diff，您可以通过-b或--ignore-space-change来忽略修补程序中空白区域的更改。

如果您使用emacs并且已经发送了补丁，您还可以使用M-x diff-ignore-whitespace-hunk重新格式化补丁以忽略特定块中的空格。或者diff-refine-hunk突出显示字符级别的字符更改，这往往会指出更改的“肉”。

对于应用补丁，您可以使用带有GNU补丁的-l或--ignore-whitespace来忽略制表符和空格的更改。小心Python代码： - ）

Answer 2

我不知道git diff。但是，类似差异的工具不仅可以理解缩进，而且实际上我们的目标语言中的任何布局更改都是Smart Differencer。

此工具以与编译器相同的方式解析代码的前后版本，并比较生成的语法树，因此它不受任何空格更改（除语义上重要的空格，如Python缩进）的影响善意的，插入的或删除的评论，甚至是常数的基数改变。

结果是报告程序员编辑操作（“移动，插入，删除，复制，重命名”）语言结构（表达式，语句，声明，块，方法......）而不是“插入行”或“删除行”。

Answer 3

值得一提的是，使用git difftool和meld或xxdiff等工具可以让差异更具可读性。

Answer 4

我尝试不在与其他一些更改相同的提交中进行文件范围的缩进更改。并且我在一个单独的提交之前或之后提交缩进更改，使用“仅更改缩进”的提交消息，以使其清楚，以便不需要手动差异检查，以查看是否有其他更改。