2

我喜欢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在搜索历史时，我对传递额外的选项并不感兴趣。

4

1 回答 1

1

理论上可以创建您的两个场景，但都不会产生您想要的输出，因为“更改”仍将被检测为提交 C 的一部分。两者都需要大量的手动工作才能到达那里。（我必须测试在毫无根据的合并中会发生什么，但第二种情况实际上可能会通过合并删除您的 repo 中的所有其他文件。）

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

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

如果您真的想消除空白更改，因此 vanilla blame 将为您提供所需的输出，那么您最好的选择是交互式 rebase，您可以在初始提交的消息和作者下将这些提交压缩在一起，但这当然假设您没有t 将代码推送到遥控器，这需要人工干预。

我知道您说您不想将额外的选项传递给责备，但最简单和最一致的选项是传递-w标志，并且责备将或多或少地执行您的用例描述的操作，并告诉您最后的提交对行进行实质性（非空白）更改。

于 2017-09-12T05:08:13.377 回答