Git blame -M:意外行为

Question

当使用git blame -M来检测一个文件内的代码移动时，我得到的结果我无法向自己解释。

首先提交以下文件(file.cpp):

void func1(){return;}[CR][LF]
int func2(){return 23;}[CR][LF]    

然后我通过移动第一行的内容并添加新的内容来修改它:

float newFunc(){return 23.0;}[CR][LF]
int func2(){return 23;}[CR][LF]
[CR][LF]
[CR][LF]
void func1(){return;}[CR][LF]

日志现在看起来如下:

>git log --oneline -2
18c670f modified file.cpp
92b4186 added file.cpp

现在我开始责备:

git blame -s -w -M file.cpp
18c670fa 1) float newFunc(){return 23.0;}
92b4186d 2) int func2(){return 23;}
18c670fa 3)
18c670fa 4)
18c670fa 5) void func1(){return;}

我想知道为什么包含func1()的行没有被识别为移动。我试图减少所需字符的数量(即-M4等)。此外，由于有-w选项，空格应该无关紧要。

Answer 1

(3年后)

我想知道为什么包含func1()的行没有被识别为移动。

这可能与最近(2016年7月)修复的即将发布的git 2.10的错误有关:

见David Kastrup (fedelibre)的commit 17a07e2(2016年5月28日)。
^{(由juno C Hamano—gitster—在commit 7418a6b中合并，2016年7月19日)}

blame:使用-M

查找移动行时需要0上下文行

git blame -M的核心部分需要1上下文行，但是在代码中找不到任何基本原理;它会产生伪影就像在"理解git blame -M的行为"中讨论的那样。

函数diff_hunks是diff引擎的包装器。将上下文长度显式地放入此包装器中(而不是不传递参数，只是将上下文长度设置为零)函数)清楚地表明有人需要调用它不同的值。

文件中没有说明为什么到目前为止我记得。
也许它会崩溃或者陷入无限循环。也许它可以在某个时间点这样做，但现在不再这样做了。

不确定它是否有帮助，但ctxlen = 1似乎被添加回d24bba8(git-pickaxe -M:责备文件内的行移动).

似乎没有检测单线移动是每个设计，只是文档不精确关于这个。这样的增强可以被认为是一个功能请求吗?

这个线程对之前选择的历史有了更多的了解。

唯一暗示我们为什么要考虑非零上下文的东西这是一个好主意，我说:

我们可能需要使用一些周围的上下文行，以便通过"ciff"算法更好地识别复制源，但这是一个次要的实现细节。