git diff，显示删除和添加的同一行

git diff, shows the same line as both deleted and added

提问by Pumpkin

I accidently worked on the master where I had to open up a new branch.

我不小心在 master 上工作，我不得不在那里开设一个新分支。

I reverted it to its original form almost completely. At one class I get the following diff that I can not make sense out of.

我几乎完全恢复了它的原始形式。在一节课上，我得到了以下我无法理解的差异。

index 4a9abb8..7c55879 100755
--- a/includes/site.inc.php
+++ b/includes/site.inc.php
@@ -142,11 +142,11 @@ class site{

        public $tplEngine = 'smarty';

-
+       
     private $_productsByType = array();
     private $logger;
-    protected $locale = 'tr_TR';
-
+    protected $locale = 'tr_TR';  
+    

It says that I have deleted and added the same thing, in principle there is no difference with the original index and I don't want this file to be seen as modified.

它说我删除并添加了相同的内容，原则上与原始索引没有区别，我不希望将此文件视为已修改。

What should I do ? Thx.

我该怎么办 ？谢谢。

采纳答案by jpe

Check spaces. The replaced "empty" looking lines have spaces in them. You may also have accidentally replaced tabs with spaces or vice versa.

检查空格。替换后的“空”外观线中有空格。您也可能不小心用空格替换了制表符，反之亦然。

回答by mamapitufo

It's probably whitespace changes. You can run git diff -w, which will ignore any whitespace changes.

这可能是空格更改。您可以运行git diff -w，它将忽略任何空格更改。

回答by MKM

In addition to spaces/tabs, line endings when entered from different editors (even on Windows) and/or different OSs can contribute to diff lines showing duplicates; LF (linux/Unix) vs CRLF (Windows).

除了空格/制表符，从不同的编辑器（甚至在 Windows 上）和/或不同的操作系统输入时的行尾可能会导致显示重复的差异行；LF (linux/Unix) 与 CRLF (Windows)。

回答by carlspring

Check for spaces or line ending differences.

检查空格或行尾差异。

回答by Kevin Reid

The second version of the nonblank line has a space after the semicolon and the blank lines also have different numbers of spaces.

非空行的第二个版本在分号后有一个空格，空行也有不同数量的空格。

There should be an option to have git highlight such hidden spaces so the diffs are more informative, but I don't have the manual handy.

应该有一个选项让 git 突出显示这些隐藏的空间，以便差异提供更多信息，但我手头没有手册。

回答by dgruending

As trailing spaces are sometimes not shown in the command line output, using

由于命令行输出中有时不显示尾随空格，因此使用

git difftool

after specifying, e.g., vimdiff as your difftool via git config --global diff.tool vimdiffmay help.

在指定例如 vimdiff 作为您的 difftool via 之后git config --global diff.tool vimdiff可能会有所帮助。

回答by Adam Rosenfield

This can sometimes happen because the default diff algorithm used by git uses a heuristic to cut out expensive edge cases, which can result in suboptimal results.

有时会发生这种情况，因为 git 使用的默认 diff 算法使用启发式方法来剔除昂贵的边缘情况，这可能会导致次优结果。

I ran into an identical issue to this that I couldn't explain due to whitespace, line endings, etc. git diffwas showing a particular line that was deleted and then re-added, as part of a hunk that was displayed as 3 lines deleted and 2 lines added but was in reality 2 lines deleted and 1 line added. Other diff programs showed the expected 2 lines deleted and 1 line added.

我遇到了与此相同的问题，由于空格、行尾等，我无法解释 git diff它显示了一个特定的行，该行被删除然后重新添加，作为显示为 3 行删除和添加了 2 行，但实际上删除了 2 行并添加了 1 行。其他 diff 程序显示了预期的 2 行删除和 1 行添加。

The file in which this happened was 4736 lines (114 KB), with diffs totaling as 640 insertions and 1340 deletions, with the hunk in question being in the middle of the file. I was unable to reduce it to a smaller test case that exhibited the same problem: making the slightest perturbations anywhere made the problem go away. My only conclusion is that I was falling into one of these edge cases of the diff algorithm's heuristic.

发生这种情况的文件有 4736 行 (114 KB)，差异总计为 640 次插入和 1340 次删除，有问题的大块位于文件的中间。我无法将其简化为展示相同问题的较小测试用例：在任何地方进行最轻微的扰动都会使问题消失。我唯一的结论是我陷入了 diff 算法启发式的这些边缘情况之一。

Git supports multiple other diff algorithmsbesides the default. By switching the algorithm to any of minimal, patience, or histogram, my problem went away in this case.

除了默认值之外，Git 还支持多种其他差异算法。通过将算法切换到minimal、patience、 或 中的任何一个histogram，我的问题在这种情况下就消失了。

See also this commentin the git source code, from the embedded LibXDiff library.

另请参阅来自嵌入式 LibXDiff 库的 git 源代码中的此注释。

回答by VonC

Note that git 1.8.4 (July 2013)will no longer show you changes with only empty lines, if you are using the new -Boption.

请注意，如果您使用新选项，git 1.8.4（2013 年 7 月）将不再仅显示空行的更改-B。

"git diff" learned a mode that ignores hunks whose change consists only of additions and removals of blank lines, which is the same as "diff -B" (ignore blank lines) of GNU diff.

“ git diff”学习了一种忽略大块的模式，其更改仅包括添加和删除空行，这diff -B与GNU diff的“ ”（忽略空行）相同。

See commit 36617af7ed594d1928554356d809bd611c642dd2:

见提交 36617af7ed594d1928554356d809bd611c642dd2：

The goal of the patch is to introduce the GNU diff -B/--ignore-blank-linesas closely as possible. The short option is not available because it's already used for "break-rewrites".

When this option is used, git diffwill not create hunks that simply add or remove empty lines, but will still show empty lines addition/suppression if they are close enough to "valuable" changes.

here is a more thorough description of the option:

• real changes are interesting
• blank lines that are close enough (less than context size) to interesting changes are considered interesting (recursive definition)
• "context" lines are used around each hunk of interesting changes
• If two hunks are separated by less than "inter-hunk-context", they will be merged into one.

补丁的目标是-B/--ignore-blank-lines尽可能接近地引入 GNU 差异。短选项不可用，因为它已用于“ break-rewrites”。

使用此选项时，git diff不会创建简单地添加或删除空行的块，但如果它们足够接近“有价值的”更改，仍将显示空行添加/抑制。

以下是对该选项的更详尽描述：

• 真正的变化很有趣
• 与有趣的变化足够接近（小于上下文大小）的空行被认为是有趣的（递归定义）
• “上下文”线用于围绕每个有趣的变化
• 如果两个大块之间的距离小于“大块间上下文”，则它们将合并为一个。