Hello Torsten,
Torsten Bögershausen, Sonntag, 9. August 2015 22:20:
> On 2015-08-08 07.58, Torsten Bögershausen wrote:
>> On 2015-08-07 18.32, Benkstein, Frank wrote:
>>> 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 <tbo...@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)
You were right. They are CRLF in my working tree. My editor tricked me.
>> 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.
You are correct that it is also wrong in git v1.7.0. However, it is correct in
v2.4.0.
Another bisect gave me this commit which was included in v2.0.1:
commit 4d4813a52f3722854a54bab046f4abfec13ef6ae
Author: brian m. carlson <sand...@crustytoothpaste.net>
Date: Sat Apr 26 23:10:40 2014 +0000
blame: correctly handle files regardless of autocrlf
So this still looks like a regression v2.5.0 to me.
Regards,
Frank.
