Why would a line's SHA in a git blame view have a leading caret (^)?

Question

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! 

Steps to Reproduce

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?

Answer 1

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.