2

当使用 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 选项，空格应该无关紧要。

4

1 回答 1

1

（3年后）

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

这可能与最近（2016 年 7 月）为即将发布的 git 2.10 修复的错误有关：

请参阅David Kastrup ( )的提交 17a07e2（2016 年 5 月 28 日） 。（由Junio C Hamano 合并——在提交 7418a6b中，2016 年 7 月 19 日）fedelibre
gitster

blame: 需要 0 个上下文行，同时查找移动的行-M

需要 1 个上下文行的核心部分git blame -M，但在代码中找不到理由；它会导致像该线程“理解行为git blame -M”中讨论的伪影。

该函数diff_hunks是diff引擎的包装器。
将上下文长度显式放入此包装器中（而不是不传递参数而只是在函数中将上下文长度设置为零）清楚地表明有人希望使用不同的值调用它。

据我记得，文件中没有文档或理由。
也许它会崩溃或陷入无限循环。也许它可以在某个时间点这样做，但现在不再这样做了。

不确定它是否有帮助，但ctxlen = 1似乎被添加回d24bba8 （git-pickaxe -M：文件中的责备行移动）。

似乎不检测单线运动是每个设计，只是文档对此并不精确。这种增强可以被视为功能请求吗？

该线程对先前选择的历史有了更多的了解。

唯一可以远程暗示为什么我们认为非零上下文是个好主意的事情是 this，我在其中说：

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

于 2016-07-20T07:12:28.303 回答