Subject: Re: git blame breaking on repository with CRLF files

From: Torsten Bögershausen <[email-masked]>
Date: Sat, 8 Aug 2015 07:58:51 +0200

On 2015-08-07 18.32, Benkstein, Frank wrote:
> Hello,
> 
> I am working working on Linux and am examining code in a git repository I do
> not know much about.  I am only looking at files, not changing anything.  On
> some files in the repository I get "00000000 (Not Committed Yet" for all lines
> when running "git blame".  I checked with "git status", "git reset", "git
> clean" that the files are indeed in the repository and unmodified.  I noticed
> that this only happens with git v2.5.0.  With git v2.4.0 it looks correct, i.e.
> the output has proper commit ids, Author names and dates..  With "git bisect" I
> tracked this down to the following commit:
> 
>  commit 4bf256d67a85bed1e175ecc2706322eafe4489ca (HEAD, refs/bisect/bad)
>  Author: Torsten Bögershausen <[email-masked]>
>  Date:   Sun May 3 18:38:01 2015 +0200
> 
>      blame: CRLF in the working tree and LF in the repo
> 
> Digging further, it seems that most files in the repository are checked in with
> CRLF line endings.  In my working tree these are checked out as LF
Do I understand it right that you have files in the repo with CRLF ?
And these files are checked out with LF in the working tree ?
Are the files marked with .gitattributes ?
Or does the file have mixed line endings ?

(Unless I missed something: Git never strips CRLF into LF at checkout,
so I wonder how you ended up in this situation)

Is there a way to reproduce it?

 - which
> seems to be the exact opposite situation of what the commit is trying to
> address.  When I set "core.autocrlf" to "false" I also get the correct behavior
> of "git blame" - this is a workaround as long as I do not have to actually
> modify anything.
> 
> Best regards,
> Frank.