我喜欢使用git blame
作为第二种形式的文档。检查提交的原因,以及何时以及由谁进行提交确实很有用。
但有时某条线的历史会丢失。可能发生这种情况的一些情况:
进行了更改,但之后又进行了更改。
有人重新缩进文件并提交。 之后,标准缩进将被恢复并提交。
有人将文件复制到没有历史记录的新分支/存储库中。 我仍然在分支中拥有原始历史记录,我想将其合并到新分支中。
在所有这些情况下,git blame
将显示文件的最新更改,这通常不是很有用。例如。 “Restore indentation”或“Revert commit#123”或“Initial commit:all files”。
有没有办法提示git blame
我们对旧历史比对新历史更感兴趣?
情况如下:
... - A - B - C
我想知道我们是否可以与优先级父级执行神奇的git合并:
.-------.
/ \
... - A - B - C - D
git blame
要遵循的优先级历史记录。我认为可以接受的另一种可能性:
E - F
\
... - A - B - C - D
我希望永远成为历史的一部分。在搜索历史记录时,我并不想将额外的选项传递给git blame
。
答案 0 :(得分:1)
理论上可以创建两个场景,但不会产生您想要的输出,因为"更改"仍然会被检测为提交C的一部分。并且两者都需要大量的手工工作才能实现。 (我必须测试无基础合并中发生的情况,但第二种情况可能实际上会删除合并中的所有其他文件。)
请记住,git存储代码的快照以及文件名,文件夹,行,提交消息等等,更像是描述git大脑内容的元数据。
Git责备本质上只关心当前blob的内容以及该代码的来源。它不会在合并的分支和代码之间看到更改,并继续寻找与报告不同的提交。
如果你真的想要消除空格的变化,那么vanilla blame会给你你想要的输出,你最好的选择就是一个交互式的rebase,你可以在最初的提交消息和作者的基础上将这些提交压缩在一起,但是当然,假设您没有将代码推送到遥控器,这又需要手动干预。
我知道你说你并不想传递额外的选项,但最简单和最一致的选择是传递-w
标志,责备会或多或少地做你的用例描述并告诉你对该行的最后一次实质性(非空白)更改的提交。