说服 git blame 一个分支比另一个分支更相关于历史记录

Question

我喜欢使用 git blame 作为次要文档形式。它非常有用，可以检查为什么进行了提交，何时以及由谁进行的。

但是有时候会丢失特定行的历史记录。以下是可能发生这种情况的一些情况：

• 进行更改，但随后撤销了更改。

• 某人重新缩进文件并提交。 稍后恢复标准缩进并提交。

• 某人将文件复制到没有历史记录的新分支/存储库中。 我仍然在一个分支中拥有原始历史记录，我想将其合并到新分支中。

在所有这些情况下，git blame 将显示文件的最新更改，这通常不太有用。例如，“还原缩进”或“撤消提交＃123”或“初始提交：所有文件”。

是否有任何方法提示 git blame 我们对旧历史记录更感兴趣而不是新历史记录？

以下是情况：

... - A - B - C

• Commit A中的所有行都有良好的注释。
• Commit B重新缩进了整个文件。
• Commit C(可能是一个还原操作)将文件恢复到了Commit A的状态。

我想知道是否可以执行一个具有优先级父级的神奇的Git合并：

        .-------.
       /         \
... - A - B - C - D

• 提交 D 告诉 Git A 是 git blame 跟随的优先历史记录。

另一个我认为可以接受的可能性：

            E - F 
                 \
... - A - B - C - D

• 提交 E 是一个新的空分支。
• 提交 F 仅添加了关注的文件。
• 提交 D 合并了两个历史，使 F 成为历史的优先。

我希望将其永久地纳入历史记录中。当搜索历史记录时，我不太想传递额外的选项给 git blame。

- joeytwiddle

---

一个切入点的观察：昨天dev1和dev2都将相同的三行修复代码粘贴到他们的分支中。（由于它们实际上并不冲突，git 不会在两个分支上改变这些行，并且可以自动合并它们。）我昨天将dev1的分支合并到了master中，他出现在了 git blame 中。今天我将dev2的分支合并到了master中，现在dev2出现在了 git blame 中。但是如果我回去使用 git merge -s ours dev2 进行合并，那么 git blame 中就会出现dev1而不是dev2。我想知道是否仍有希望... :) - joeytwiddle

Answer 1

你提出的两种情况理论上都可以创建，但都无法产生你想要的输出结果，因为"更改"仍然会被检测到作为提交C的一部分。而且这两种情况都需要大量手动工作才能实现。（我必须测试在无基础合并中会发生什么，但第二种情况实际上可能会删除存储库中的所有其他文件与合并。）

请记住，Git存储代码的快照，像文件名、文件夹、行、提交消息等等都是元数据，用于描述Git大脑内部的内容。

Git blame本质上只关心当前blob的内容和代码的来源。它不会看到合并分支和代码之间的更改，并继续寻找不同的提交来报告。

如果你真的想消除空格更改，使vanilla blame给出你想要的输出结果，最好的选择是交互式变基，在初始提交的消息和作者下将这些提交压缩在一起，但前提是你没有将代码推送到远程，这还需要手动干预。

我知道你说过不想向blame传递额外的选项，但最简单和最一致的选项是传递-w标志，blame将会做出更多或更少符合你使用情况的描述，并告诉你该行最后一个实质性（非空格）更改的提交。

- LightBender