Git blame -L bug?

Question

我正在运行带有多个 -L 选项的 git blame -L，以便在单个 git 调用中获取非顺序行的行信息。

我相信这个电话：

git blame -L38,38 -L40,40 <file>

应等效于分别进行的这 2 个调用

git blame -L38,38 <file>
git blame -L40,40 <file>

但是，我遇到了一种情况，其中使用多个 -L 选项实际上返回了第 38 行和第 39 行，而不是预期的第 38 行和第 40 行：

$ git blame -L38,38 -L40,40 <file>
b6543ffe (Some Body 2015-11-24 15:15:03 -0500 38)           SOME CODE
b6543ffe (Some Body 2015-11-24 15:15:03 -0500 39)           SOME OTHER CODE

当我只有一个 -L40,40 时，git 实际上正确返回第 40 行：

$ git blame -L40,40 <file>
b6543ffe259 (Some Body 2015-11-24 15:15:03 -0500 40)                SOME CODE

我是否缺少有关 -L 实际工作原理的内容，或者这是一个 git 错误？

我尝试同时使用 git 版本 2.7.0.windows.1 和 2.11.0.windows.1。

Answer 1

它应该(你可以看到它在2013年的这个补丁系列中是如何实现的)

但它显然不是(可能是一个错误).
这导致一些项目，如isaacbernat/pycrastinate修复 git 责备多行范围

此修复程序分别调用每行的 git 责备。

>更新 2020 年 8 月

在 Git 2.29(2020 年第 4 季度)之前，当给定多个目标行范围时，"git blame -La,b -Lc,d^(man)"过于急于合并原始行组并显示不正确的结果，这已得到纠正。

请参阅提交 c2ebaa2、提交 dd7c611、提交 6dbf0c7(2020 年 8 月 13 日)，作者：Jeff King (peff).
^{(由 Junio C Hamano --gitster-- 合并于 提交 93121df，2020 年 8 月 19 日)}

blame：仅合并结果中相邻的线

^{报告人：Nuthan Munaiah
签名者：Jeff King}

在责备结束后但在我们产生任何输出之前，我们合并了原始嫌疑人中相邻的行组(这些行可能已被中间提交的行分开，这些行消失了)。

但是，如果结果中的行不相邻，这可能会导致输出不正确。
例如，t8003 中的情况有：

ABC
DEF  

这成为

ABC
SPLIT
DEF  

在结果中仅责备第 1 行和第 3 行会产生两个在原始中相邻的责备组(每行一个).
这足以让我们将它们合并为一个组，但这会丢失信息：我们的输出例程假设它们在结果中也是相邻的，我们输出：

<oid> 1) ABC
<oid> 2) SPLIT  

这是无稽之谈，原因有二：

• 我们被问到第 3 行，而不是第 2 行;我们根本不应该输出 SPLIT 行。
• 提交<oid>根本没有触及 SPLIT 行！
  我们找到了第 3 行的正确责备，但错误实际上处于输出阶段，它显示了最终文件中错误的行号和内容。

我们可以通过仅在嫌疑线和结果线相邻时才合并来解决此问题。这修复了这个错误，但在需要的情况下会继续合并(例如，t8003 中的现有测试，其中 SPLIT 消失了，并且结果中的行确实相邻)。