Reputation: 6989
I'm not sure if this behavior is bizarre, but here's what's happening: it seems if I run git blame
on a file, any lines in that file that are from the initial commit have a SHA with a leading caret (^
), like this
^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!
From a terminal prompt:
mkdir newProject
cd newProject
git init
echo 'hello, world!' >> testFile.txt
git add testFile.txt
git commit -m "Initial Commit"
git blame testFile.txt
Then verify your blame output has a leading caret, as mine did (though your SHA likely won't match)
^bb65026 (Brian Danielak 2012-10-27 19:11:54 -0700 1) hello, world!
As a test, you can try adding a second line to a file and re-committing, to see that only the hash of the first line contains a leading caret
echo 'hello again!' >> testFile.txt
git add testFile.txt
git commit -m "Initial Commit"
git blame testFile.txt
My blame output now looks like this:
^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!
Can anyone explain why this happens, and whether I should have expected it? Does it only happen when a line comes from the first commit in a repo? If so, why?
Upvotes: 25
Views: 2671
Reputation: 15552
I ran into this issue suddenly in a very old repository and was confused by it.
The problem ended up being that I had somehow gotten a shallow clone at some point. A simple git fetch --unshallow
remedied it.
Upvotes: 6
Reputation: 258208
The docs for git blame actually do mention the caret as being used for a "boundary commit", which it looks like they're defining something like "the oldest commit in this blame range" -- in your case it's the project's initial commit, but with some different options you may have only blamed up to commits from 3 weeks ago.
Upvotes: 25