Re: git blame breaking on repository with CRLF files

["Torsten Bögershausen" <tboegi@web.de>]

On 2015-08-08 07.58, Torsten Bögershausen wrote:
> 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 <tboegi@web.de>
>>  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?
> 
Actually I could reproduce the following:
CRLF in repo, CRLF in working tree, core.autocrlf= true.

This is an old limitation (or call it bug), which has been there for a long
time, (I tested with Git v1.7.0 from 2010).

Thanks for the report, we will see if anybody is able to fix it.
I can probably contribute some test cases.

>> 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.