我喜欢使用git blame作为文档的辅助形式。 检查提交的原因以及何时以及由谁进行非常有用。
但有时特定生产线的历史会丢失。 可能会发生这种情况的一些情况：
-
进行了更改，但随后还原。
-
有人重新缩进文件并提交它。 稍后恢复并提交标准缩进。
-
有人将文件复制到没有历史记录的新分支/存储库中。 我在分支中仍然有原始历史记录，我想将其合并到新分支中。
在所有这些情况下，git blame将显示对文件的最新更改，这通常不是很有用。 例如，"恢复缩进"或"恢复提交 #123"或"初始提交：所有文件"。
有没有办法暗示git blame我们对旧历史比对新历史更感兴趣？
情况如下：
... - A - B - C
- 提交 A 对文件中的所有行都有很好的注释。
- 提交 B 重新缩进了整个文件。 提交
- C(可能是还原)将文件还原到提交 A 中的样子。
我想知道我们是否可以与优先级父级执行神奇的 git 合并：
.-------.
/
... - A - B - C - D
- 提交 D 告诉 git，A 是
git blame遵循的优先级历史记录。
我认为可以接受的另一种可能性：
E - F
... - A - B - C - D
- 提交 E 是一个新的空分支。
- 提交 F 仅添加关注的文件。
- 提交 D 合并了两个历史记录，使 F 成为历史记录的优先级。
我希望使这成为历史的永久一部分。 我对在搜索历史记录时传递额外的选项git blame并不感兴趣。
理论上可以创建这两种方案，但都不会产生所需的输出，因为"更改"仍会被检测为提交 C 的一部分。两者都需要大量的体力劳动才能到达那里。(我必须测试在毫无根据的合并中会发生什么，但第二种情况实际上可能会通过合并删除存储库中的所有其他文件。
请记住，git 存储代码的快照，文件名、文件夹、行、提交消息等更像是描述 git 大脑内部内容的元数据。
Git blame 本质上只关心当前 blob 的内容以及代码的来源。它不会看到合并的分支和代码之间的变化，并继续寻找与报告不同的提交。
如果你真的想消除空格更改，以便原版责备会给你你想要的输出，你最好的选择是交互式变基，你在初始提交的消息和作者下将这些提交压缩在一起，但这当然假设你没有将代码推送到远程，这需要手动干预。
我知道你说过你不想传递额外的选项来责备，但最简单和最一致的选择是传递-w标志，责怪将或多或少地完成你的用例描述，并告诉你最后一次实质性(非空格)更改的提交到行。