Git责备-L错误？

Question

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

我相信这个电话：

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

应该相当于这两个分别调用

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

应该（您可以在this patch series in 2013 中看到how it was implemented）

但它显然不是（可能是一个错误）。
这导致了一些像isaacbernat/pycrastinate 这样的项目到Fix for git blame multiple line ranges

此修复程序分别为每一行调用 git blame。

---

2020 年 8 月更新

在 Git 2.29（2020 年第四季度）之前，当给定多个目标行范围时，“git blame -La,b -Lc,d^(man)”过度渴望合并原始行组并显示不正确结果，已更正。

参见Jeff King (peff) 的commit c2ebaa2、commit dd7c611、commit 6dbf0c7（2020 年 8 月 13 日）。
^{（由 Junio C Hamano -- gitster -- 合并到 commit 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 行
• commit <oid> 根本没有触及 SPLIT 行！
  我们找到了第 3 行的正确原因，但错误实际上是在输出阶段，它显示了错误的行号和最终文件的内容。

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