RE: git blame breaking on repository with CRLF files

2015-08-10 Thread Benkstein, Frank 
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  (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 +

 blame: correctly handle files regardless of autocrlf

So this still looks like a regression v2.5.0 to me.

Regards,
Frank.

git blame breaking on repository with CRLF files

2015-08-07 Thread Benkstein, Frank 
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  (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 - 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.