gitk相当于git log --follow <文件完整路径>

Question

我有一个名为one.txt的文件，这些年来一直在主分支上修改。使用gitk one.txt将显示该特定文件的整个历史记录。然而，在我将one.txt更改为two.txt后，gitk two.txt不显示重命名之前的任何更改。

我尝试过gitk --follow two.txt，但仅提供每个提交的注释，没有实际的文件更改信息。

我知道可以执行git log --follow two.txt，但必须针对每个SHA1值执行gitk以查看正在更改的内容。

那么有什么提示吗？

- nobody

---

看看https://dev59.com/5GYq5IYBdhLWcg3wzDhI#25090142 ...我写了一行代码，可以实现你想要的功能。 - Brian Vandenberg

Answer 1

问题是 gitk --follow将与git log --follow目前不同，考虑到根据 Linux Torvalds 的说法，--follow主要是一个 hack。

我十分确定在发布最初的补丁时，我提到了这个确切的问题，基本上可以概括为："--follow"是一个彻底的 hack，并不使用常规的提交过滤函数，因此像"--parent"这样的高级功能与其配合效果并不好。

换句话说，我对它是否可修复并不确定。"--follow 是一种非常根本性的非常 Git 的操作方式，实际上是一个完全的 hack。从源代码上看，这个 hack 虽然相对简单，如果你不知道更多细节，也许会认为它很自然地适应了 Git。但事实并非如此。

现在，我们可能可以通过修改 --parent 来使其与 --follow 兼容，但坦率地说，我不知道该如何做。因为 --follow 的 hack 实际上基本上可以概括为：

- 完全不剪枝提交（这通常会简化父子关系并删除不感兴趣的提交） - 对 "git log" 中的所有普通提交进行补丁生成，并使用专门的魔法特殊 hack 来查找重命名。 - 如果是重命名，则更改我们神奇追踪的路径，以便下一个要查看的提交将沿着新（旧）路径进行追踪。 - 如果补丁为空，我们强制隐藏该提交（在内部，这是 "rev->always_show_header = 0;" 的设置）

而关键在于，我们在队列的末尾进行所有魔法操作，而这是在通常完成父子关系重命名的提交剪枝之后才执行的。

抱歉，我偶尔会使用 --follow，但它只是一种“hack”来查看“好了，它被重命名了”。如果 "gitk --follow <pathname>" 能正常工作就好了，但这并不是我非常关心的事情。

---

另一个区别是路径规范魔法的支持：在 Git 2.42（2023 年第三季度）之前，"git [-c log.follow=true] log [--follow] ':(glob)f**'" 会导致错误。

查看提交 8260bc5，提交 9eac595，提交 8e32caa（2023年6月1日）由Jeff King (peff)完成。
^{（由Junio C Hamano -- gitster --在提交 de00f4b中合并，2023年6月20日）}

diff：检测到--follow不支持的路径规范魔法 报告者：Jim Pryor 签名者：Jeff King

--follow代码无法处理大多数形式的路径规范魔术。
我们通过运行时的GUARD_PATHSPEC()检查来确保没有意外的路径规范魔术进入try_to_follow_renames()，这样就会出现以下行为：

$ git log --follow ':(icase)makefile' >/dev/null
BUG: tree-diff.c:596: 不支持的魔术 10
Aborted

":(glob)"、":(attr)"等也是如此。
很好，我们注意到了问题，而不是继续执行并产生错误答案。
但是有两个非理想的地方：

1. GUARD_PATHSPEC()的目的是捕获低级代码遇到意外路径规范的编程错误。
   通常我们会尝试通过向parse_pathspec()传递magic_mask来捕获不支持的路径规范，这样用户会得到更好的消息，例如：

   该命令不支持路径规范魔术：'icase'
   

   这里没有发生这种情况，因为git-log通常支持所有类型的路径规范魔术，所以它将"0"作为掩码传递 （这个调用实际上发生在setup_revisions()中）。它需要区分正常情况和"--follow"情况，但目前还没有。

2. 除了--follow之外，我们还有log.follow配置选项。
   当设置了该选项时，我们只在存在单个路径规范时尝试启用--follow模式（因为--follow无法处理其他情况）。
   但是，实际上应该扩展为"当路径规范支持时使用--follow"。
   否则，每次使用奇特的路径规范时都会出现问题：

   $ git config log.follow true
   $ git log ':(icase)makefile' >/dev/null
   BUG: tree-diff.c:596: 不支持的魔术 10
   Aborted
   

   如果此特定调用不支持跟踪模式，我们应该避免启用它。

此补丁扩展了我们的diff_check_follow_pathspec()函数以涵盖路径规范魔术，解决了这两个问题。

- VonC

---

唉... 他总是这样子。他应该关心一下这个问题 >.< - nobody

@Cawas 我在 git 的日志中没有看到任何进展（https://github.com/git/git/tree/master/Documentation/RelNotes）。 - VonC

我差不多要开一个新问题了，Von... 到目前为止，这是我最接近找到 --follow 不能正确跟踪文件的原因，关于 git（而不是 gitk）。如果有二进制文件，是否会有影响？你有什么指针吗？ :P - cregox

只想提一下，在Linus的摘录中，--follow有时会做正确的事情，即使在gitk中不是这样。在VonC和Cawas发现的线程（"Git log follow question"），Linus说："'git log --follow' 很好用。 'git blame -C'也是如此。"但是“git log”并不总是能做到你希望的事情：“像'--parent'这样的花哨的东西在它身上并不能很好地运作。” - Chris

这是重构项目结构的主要障碍。在gitk上最接近本地的解决方法是使用文件掩码过滤提交（并将其存储为视图），当然，对于超出简单文件移动（例如将abc重命名为xyz）的提交来说，这是无用的。 - prusswan