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@xxxxxx> >> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html