git - 为什么 git blame 不遵循重命名？

Question

$ pwd
/data/mdi2/classes

$ git blame -L22,+1 -- utils.js
99b7a802 mdi2/utils.js (user 2015-03-26 21:54:57 +0200 22)  #comment

$ git blame -L22,+1 99b7a802^ -- utils.js
fatal: no such path mdi2/classes/utils.js in 99b7a802^

正如您所注意到的，该文件在该提交中位于不同的目录中

$ git blame -L22,+1 99b7a802^ -- ../utils.js
c5105267 (user 2007-04-10 08:00:20 +0000 22)    #comment 2

尽管在文档中

The origin of lines is automatically followed across whole-file renames (currently there is no option to turn
       the rename-following off)

blame 不跟随重命名。为什么？

更新:简答
git blame遵循重命名但不是为 git blame COMMIT^ -- <filename>
但是，通过大量重命名和大量历史记录手动跟踪文件重命名太难了。
我认为，必须修复此行为以静默遵循 git blame COMMIT^ -- <filename> 的重命名.或者，至少， --follow必须实现，所以我可以: git blame --follow COMMIT^ -- <filename>
更新 2:那是不可能的。参见下文。

来自邮件列表的答复 通过 Junio C Hamano

git blame follow renames but not for git blame COMMIT^ -- <filename>

假设您的版本 v1.0 中有文件 A 和文件 B。

六个月后，代码被大量重构，你做到了
不需要分开这两个文件的内容。你有
删除了 A 和 B，他们拥有的大部分内容现在都在文件 C 中。那就是
当前状态。

git blame -C HEAD -- C

可以遵循两者的内容就好了，但如果你是
允许说

git blame v1.0 -- C

这到底是什么意思？ C 根本不存在 v1.0。你是
要求跟随A的内容，还是B？你是怎么
当你在这个命令中告诉它 C 时，告诉你是 A 而不是 B？

“git blame”跟随内容移动，从不处理“重命名”
任何特殊的方式，因为认为重命名是一件愚蠢的事情
有点特别;-)

你告诉命令从什么内容开始挖掘的方式
从它的命令行是给出起点提交(默认为
HEAD，但您可以以 COMMIT^ 为例)以及其中的路径
初始点。因为将 C 告诉 Git 和
然后神奇地让它猜测你在某些情况下是指 A 而在某些情况下是 B
其他。如果 v1.0 没有 C，唯一明智的做法是
退出而不是猜测(并且不告诉用户它是如何
猜到了)。

Answer 1

git blame确实遵循重命名(如 git log 如果你给它 --follow )。问题在于它遵循重命名的方式，这是一个不太彻底的黑客:当它一次退回一个提交(从每个 child 到每个 parent )时，它会产生差异——你可以做的同一种差异手动制作:

git diff -M SHA1^ SHA1

— 并检查此差异是否检测到重命名。1

就目前而言，这一切都很好，但这意味着对于 git blame检测重命名，(a) git diff -M必须能够检测到它(幸运的是这里就是这种情况)并且 - 这就是导致您出现问题的原因 - 它必须跨越重命名。

例如，假设提交图看起来有点像这样:

A <-- B <-- ... Q <-- R <-- S <-- T

其中每个大写字母代表一次提交。进一步假设一个文件在提交 R 中被重命名，以便在提交 R通过 T它有名字 newname而在提交 A通过 Q它有名字 oldname .

如果您运行 git blame -- newname , 序列从 T 开始, 比较 S和 T , 比较 R和 S ，并比较 Q和 R .比较时 Q和 R , git blame发现改名，开始寻找 oldname在提交中 Q更早，所以当它比较时 P和 Q它比较文件 oldname和 oldname在这两次提交中。

另一方面，如果您运行 git blame R^ -- newname (或 git blame Q -- newname )以便序列从提交 Q 开始, 没有文件 newname在那个提交中，并且在比较 P 时没有重命名和 Q , 和 git blame干脆放弃。

诀窍是，如果您从文件具有以前名称的提交开始，则必须为 git 提供旧名称:

git blame R^ -- oldname

然后一切又恢复了。

1在 git diff documentation ，你会看到有一个 -M控制方式的选项 git diff检测重命名。 blame代码稍微修改了一下(实际上做了两次传递，一次关闭 -M，第二次打开 -M)并使用自己的(不同的) -M选项用于有些不同的目的，但最终它使用相同的代码。

[ 编辑 添加对评论的回复(不适合作为评论本身)]:

Is any tool that can show me file renames like: git renames <filename> SHA date oldname->newname

不完全是，但是 git diff -M接近，并且可能足够接近。

我不确定这里的“SHA 日期”是什么意思，但是 git diff -M允许您提供两个 SHA-1 并比较左右。添加 --name-status只获取文件名和处置。因此 git diff -M --name-status HEAD oldsha1可能会报告从 HEAD 转换至 oldsha1 , git 相信你应该 R ename 一个文件，并将旧名称报告为"new"名称。例如，在 git 存储库本身中，有一个当前名为 Documentation/giteveryday.txt 的文件。曾经有一个稍微不同的名字:

$ git diff -M --name-status HEAD 992cb206
M       .gitignore
M       .mailmap
[...snip...]
M       Documentation/diff-options.txt
R097    Documentation/giteveryday.txt   Documentation/everyday.txt
D       Documentation/everyday.txto
[...]

如果那是您关心的文件，那您就很好。这里的两个问题是:

找到一个 SHA1:在哪里992cb206来自？如果您已经有了 SHA-1，那很容易；如果没有，git rev-list是 SHA1 查找工具；阅读其文档；

以及通过每次提交一次提交的一系列重命名的事实，如 git blame确实，可能会产生与将更晚的提交( HEAD )与更早的提交( 992cb206 或其他)进行比较的完全不同的答案。在这种情况下，结果是一样的，但是这里的“相似度指数”是 100 分中的 97 分。如果在某些中间步骤中对其进行了更多修改，那么该相似度指数可能会低于 50%……然而，如果我们在 992cb206 之后比较一个修订版至 992cb206 (如 git blame 会)，也许这两个文件之间的相似性指数可能更高。

需要(和缺少)的是 git rev-list自行实现 --follow ，以便所有使用 git rev-list 的命令在内部——即，大多数命令不仅适用于一个修订版——都可以做到这一点。一路上，如果它在另一个方向上工作会很好(当前 --follow 只是从新到旧，即，与 git blame 一起工作正常，并且与 git log 一起工作正常，只要你不问对于最古老的历史，首先使用 --reverse )。