如何在远程端存储库中'git blame'？

Question

在我的服务器上我托管我的个人git远程端项目（带gitosis），我已经构建了一个Web界面来浏览存储库（类似于Github）。

在远程方面，你不允许做很多事情，因为缺少一个工作树，这是正确的：顺便说一下，对于一个存储库资源管理器，我几乎可以做几乎所有命令。

git blame 除外。

我无法在远程端存储库中找到如何在没有工作树的情况下归咎于文件。你有什么想法吗？

Answer 1

以下内容甚至可以在裸存储库中使用：

git blame <rev> -- <path>

E.g。

git blame master -- README.txt

Answer 2

  

我无法找到git docs谈论的地方 - 选项，顺便说一下这个方法很有用

实际上，这是必要的，因为“git blame”准备采取 古代奇怪的论证顺序“blame <path> <rev>”除了 通常“blame [<rev>] <path>”。

这意味着，因为Git 2.17（2018年第二季度）将解释裸存储库中的“git blame HEAD COPYING”无法运行，而“git blame HEAD -- COPYING”运行正常。

但是从2.17开始，你将不再需要'--'。

commit 0c668f5见Junio C Hamano (gitster)（2018年2月5日） ^{（由Junio C Hamano -- gitster --合并于commit 0c668f5，2018年2月7日）}

  

blame：收紧命令行解析器

     

古代奇怪的论证顺序“blame <path> <rev>”除了   通常“blame [<rev>] <path>”至少有两个否定   后果：

     

  

• 为了区分这两者，它会检查最后一个命令   line参数使用命名工作树中的路径   file_exists()。
    但是，“blame <rev> <path>”是一个请求   解释存储在<path>内容中的每一行   修订版<rev>并且不需要具有工作树版本   的文件。使用file_exists()进行检查是完全错误的。

  

• 强制错误的file_exists()检查工作，代码   在执行此操作之前调用setup_work_tree()，因为它具有路径   相对于项目树的顶层   但是，“blame <rev> <path>”必须即使在裸存储库中也可以使用，   并且没有理由让setup_work_tree()抱怨   并死于“此操作必须在工作树中运行”。

  

     

要纠正前者，请切换以检查最后一个令牌是否为a   修订版（如果是这样，使用“blame <path> <rev>”解析参数   规则）。

     

通过摆脱setup_work_tree()来纠正后者   file_exists()检查 - 调用此函数的唯一情况   就是当我们运行“blame <path>”时（即没有开始修订和   要求在<path>责怪工作树文件，挖掘   HEAD修订版），但setup_scoreboard()中只有一个电话   在它调用fake_working_tree_commit()之前。

因此，简而言之，启动Git 2.17，这将在一个简单的回购中使用：

git blame master -- README.txt

使用Git 2.22时，错误消息“This operation must be run in a work tree”应该消失！

非裸存储库中的“git blame -- path”开始从工作树中发出错误，并且裸存储库中的相同命令错误，因为根据定义没有工作树。
已经教导该命令开始指责HEAD的提交， 这更有用。

commit a544fb0见SZEDER Gábor (szeder)（2019年4月7日） ^{（Junio C Hamano -- gitster --合并于commit d8620d3，2019年4月25日）}

  

blame：如果没有给出启动提交，则在裸仓库中默认为HEAD

     

在未指定启动提交的情况下调用“git blame”时   归咎于它，它从工作树中给定文件的状态开始   但是，在没有启动提交的裸存储库中调用时，   那么没有工作树状态可以从它开始，它就会死掉   以下错误消息：

$ git rev-parse --is-bare-repository
true
$ git blame file.c
fatal: this operation must be run in a work tree

     

这是误导性的，因为它暗示“git blame”不起作用   在裸存储库中，但它实际上确实工作得很好   它被赋予了从...开始的承诺。

     

当然，我们可以改进错误消息，但是让我们在裸存储库中默认为HEAD，因为很可能是用户想要的（如果他们想从另一个提交开始，那么他们会有在第一时间指定。）

     

'git annotate'只是'git blame'的一个薄包装，所以在...   同样的情况，它打印出相同的误导性错误信息，这一点   补丁修复它。