90

When I run git blame on a file (using msysgit) I always get the following sort of printout:

00000000 (Not Committed Yet 2011-01-09 11:21:30 +0200   1) package co
00000000 (Not Committed Yet 2011-01-09 11:21:30 +0200   2) {
00000000 (Not Committed Yet 2011-01-09 11:21:30 +0200   3)      impor
00000000 (Not Committed Yet 2011-01-09 11:21:30 +0200   4)      impor
00000000 (Not Committed Yet 2011-01-09 11:21:30 +0200   5)      impor
00000000 (Not Committed Yet 2011-01-09 11:21:30 +0200   6)      impor
00000000 (Not Committed Yet 2011-01-09 11:21:30 +0200   7)      impor

i.e. it shows all lines as Not Yet Committed.

I tried this on many files, that have many commits - always the same results. I also tried using relative/full path, but it seems to make no difference.

When I try to use TortoiseGit's blame it always shows every line as being last committed at the first commit:

alt text

even thought, as I've said, there are actually tens of commits in the history of these files..

Ideas?

Edit - More Info

  • Git blame works fine on GitHub, where this repo is hosted.
  • It also works fine if I clone it to a linux machine and do the blame there
  • It seems that only on msysgit this doesn't work
mikemaccana
  • 110,530
  • 99
  • 389
  • 494
Assaf Lavie
  • 73,079
  • 34
  • 148
  • 203
  • For me this problem resulted from using a symlinked path as apposed to a path that the repository recognized, so it thought the file was completely new. – Kzqai Jul 30 '12 at 20:16
  • Note: Starting git 2.0.1 (June 25th, 2014), git blame should stop reporting all those "Not Yet Committed" lines. See [my answer below](http://stackoverflow.com/a/24979164/6309) – VonC Jul 27 '14 at 08:16
  • On the mailing list: http://git.661346.n2.nabble.com/git-blame-quot-Not-Committed-Yet-quot-with-clean-WD-td7603591.html Also happens on Linux. – Ciro Santilli OurBigBook.com Jan 23 '15 at 15:43
  • This also affects WSL, so I've added the tag. Hope that's OK. – mikemaccana May 27 '20 at 11:24

4 Answers4

130

git blame file.txt blames the version of file.txt in your working copy. If file.txt has Windows-newlines (CRLF) in the repo and you have core.autocrlf = true, then every line of file.txt will be considered different and will be reported by git blame as not yet committed.

The reason why git blame <my_branch> (or even better git blame HEAD, which works no matter what branch you're on) works, is that it doesn't blame the working copy version so there's no potential for lines not yet being committed.

kusma
  • 6,516
  • 2
  • 22
  • 26
56

Found the solution - very weird.

If I run this:

git blame file.txt

The history is broken, as posted above.

If I do this instead:

git blame my_branch file.txt

It works!

This is very weird, because AFAICS the usage doesn't require a branch name:

$ git blame
usage: git blame [options] [rev-opts] [rev] [--] file
Assaf Lavie
  • 73,079
  • 34
  • 148
  • 203
9

Starting git 2.0.1 (June 25th, 2014), git blame should stop reporting all those "Not Yet Committed" lines.

See commit 4d4813a (26 Apr 2014) by brian m. carlson (bk2204).
(Merged by Junio C Hamano -- gitster -- in commit e934c67, 06 Jun 2014)

blame: correctly handle files regardless of autocrlf

If a file contained CRLF line endings in a repository with core.autocrlf=input, then blame always marked lines as "Not Committed Yet", even if they were unmodified.
Don't attempt to convert the line endings when creating the fake commit so that blame works correctly regardless of the autocrlf setting.

radon8472 adds in the comments:

the answer was git blame -w (iggnore whitespace).
The reason was that the textconv for my blamed file was working with windows linebreaks, and git blame seems to not like it, as mentioned in kusma's answer.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • 9
    I still have the problem in git v2.1.3 – DBedrenko Dec 05 '14 at 09:25
  • I have the problem with git version 2.16.1.windows.1 – Radon8472 Apr 25 '19 at 12:54
  • @Radon8472 Can you add a new question illustrating the issue, with your `git config -l` output (and a link back to this answer): that will allow me and others to try and see if the issue persists. – VonC Apr 25 '19 at 13:23
  • @VonC There is no need to do this, the answer was `git blame -w` . The reason was that the textconv for my blamed file was working with windows linebreaks, and git blame seems to not like this see @kusama s answer below – Radon8472 Mar 15 '22 at 17:49
  • 1
    @Radon8472 Thank you for the feedback. I have included your comment in the answer for more visibility. – VonC Mar 15 '22 at 21:07
1

Another possibility: case-sensitive filename typo

I had the same problem with git blame file.txt, then realized that I'd made a case-sensitive filename typo with file.txt

Changed it to File.txt (for example), and I got the expected results w/o having to specify my_branch: git blame File.txt

John Jacecko
  • 1,870
  • 1
  • 16
  • 12