0

我正在运行带有多个 -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。

4

1 回答 1

0

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

但它显然不是（可能是一个错误）。
这导致了一些项目，比如isaacbernat/pycrastinateFix for git blame multiple line range

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

2020 年 8 月更新

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

请参阅Jeff King ( )的commit c2ebaa2、commit dd7c611、commit 6dbf0c7（2020 年 8 月 13 日） 。（由Junio C Hamano 合并 -- --在提交 93121df中，2020 年 8 月 19 日）peff
gitster

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 消失了，结果中的行确实是相邻的）。

于 2016-12-03T01:30:59.160 回答