为什么git blame视图中的一行SHA有一个主要的插入符号(^)?

时间:2012-10-28 02:19:47

标签: git

我不确定这种行为是否很奇怪,但是这里发生了什么:似乎我在文件上运行git blame,该文件中的任何行都是从初始提交开始就有一个带有主要插入符号(^)的SHA,就像这个

一样
^bb65026 (Brian Danielak 2012-10-27 19:11:54 -0700 1) hello, world!
bbcd4a96 (Brian Danielak 2012-10-27 19:11:54 -0700 2) hello again!

重现步骤

从终端提示符开始:

mkdir newProject
cd newProject
git init
echo 'hello, world!' >> testFile.txt
git add testFile.txt
git commit -m "Initial Commit"
git blame testFile.txt

然后验证你的责备输出有一个主要的插入符号,就像我的那样(虽然你的SHA很可能不会匹配)

^bb65026 (Brian Danielak 2012-10-27 19:11:54 -0700 1) hello, world!

作为测试,您可以尝试在文件中添加第二行并重新提交,以查看只有第一行的哈希值包含一个前导插入符号

echo 'hello again!' >> testFile.txt
git add testFile.txt
git commit -m "Initial Commit"
git blame testFile.txt

我的责备输出现在看起来像这样:

^bb65026 (Brian Danielak 2012-10-27 19:11:54 -0700 1) hello, world!
bbcd4a96 (Brian Danielak 2012-10-27 19:11:54 -0700 2) hello again!

任何人都可以解释为什么会发生这种情况,以及我是否应该期待它?只有当一行来自回购中的第一次提交时才会发生吗?如果是这样,为什么?

2 个答案:

答案 0 :(得分:17)

git blame的文档实际上确实提到了插入符号用于“边界提交”,它看起来像是在定义类似“在这个指责范围内最老的提交” - 在你的情况下这是该项目的初始提交,但有一些不同的选项,你可能只会责怪3周前的提交。

答案 1 :(得分:2)

我在一个非常古老的存储库中突然遇到了这个问题并且对此感到困惑。

问题最终导致我在某种程度上得到了一个浅层克隆。一个简单的git fetch --unshallow补救了它。