git - git blame 使用 -L 引发错误的修订错误选项

Question

其中一个git blame选项处理行范围。手册说：

-L 仅处理行范围 n,m，从 1 开始计数

现在，我有一个超过 100 行的文件。当我运行时git blame -L 5,15 myFile.txt，git 抱怨：

致命：错误的修订版“15”

有趣的是，当我运行 git 时，它不会抱怨git blame -L 5 myFile.txt。

这是怎么回事？

Answer 1

如果您引用这些行，它将起作用

git blame -L '10,200' composer.json

Answer 2

在这种情况下，您的命令看起来是正确的。

我已经用我的 composer.json 文件检查了这个问题，它运行良好。当我尝试访问比文件内部更多的行时，我收到一个错误“文件 composer.json 只有 87 行”。

只有在第二个值之前有空格时才会出现此错误。

git blame -L 10, 200 composer.json 

fatal: bad revision '200'

所以我认为这就是问题所在。

请注意，PowerShell 和/或 Posh-Git 可能会在逗号后注入一个空格。尝试使用命令提示符。

Answer 3

注意：在 git 2.19（2018 年第三季度）中，对-L[<N>][,[<M>]]参数“ git blame”和“ git log”的解析进行了调整。

这应该避免某些情况fatal: bad revision '15'，尤其是当文件少于 15 行时：

请参阅Isabella Stephens (``)的commit 7f81c00和commit 96cfa94（2018 年 6 月 15 日） 。^{（由Junio C Hamano 合并 -- --在提交 6566a91中，2018 年 8 月 2 日）
gitster}

blame：如果范围结束超过文件末尾，则防止错误

如果该-L选项用于在 中指定行范围git blame，并且范围的结尾超出了文件的结尾，则 git 将失败并出现致命错误。 此提交可防止此类行为 - 相反，我们将责任归咎于指定范围内的现有行。

此提交还修复了两个极端情况。

• 现在责备是归咎于文件-L n,-(n+1)的第一n行，而不是n从头到尾。
• 责备-L ,-n将被视为-L 1,-n并责备文件的第一行，而不是责备整个文件。