{"thread":{"id":"40032","subject":"git blame breaking on repository with CRLF files","startedAt":"2015-08-07T16:32:58Z","lastAt":"2015-08-10T23:54:03Z","messageCount":7,"participants":["Benkstein, Frank","Torsten Bögershausen","Junio C Hamano","brian m. carlson"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"267614","messageId":"B0BFE3BB9B3E8C4A890D53FA460552D3737328B0@DEWDFEMB16B.global.corp.sap","threadId":"40032","inReplyTo":null,"subject":"git blame breaking on repository with CRLF files","fromName":"Benkstein, Frank","fromEmail":"frank.benkstein@sap.com","sentAt":"2015-08-07T16:32:58Z","receivedAt":"2015-08-07T16:32:58Z","isPatch":false,"sender":{"key":"frank.benkstein@sap.com","avatar":null},"body":"Hello,\n\nI am working working on Linux and am examining code in a git repository I do\nnot know much about. I am only looking at files, not changing anything. On\nsome files in the repository I get \"00000000 (Not Committed Yet\" for all lines\nwhen running \"git blame\". I checked with \"git status\", \"git reset\", \"git\nclean\" that the files are indeed in the repository and unmodified. I noticed\nthat this only happens with git v2.5.0. With git v2.4.0 it looks correct, i.e.\nthe output has proper commit ids, Author names and dates.. With \"git bisect\" I\ntracked this down to the following commit:\n\n commit 4bf256d67a85bed1e175ecc2706322eafe4489ca (HEAD, refs/bisect/bad)\n Author: Torsten Bögershausen \n Date: Sun May 3 18:38:01 2015 +0200\n\n blame: CRLF in the working tree and LF in the repo\n\nDigging further, it seems that most files in the repository are checked in with\nCRLF line endings. In my working tree these are checked out as LF - which\nseems to be the exact opposite situation of what the commit is trying to\naddress. When I set \"core.autocrlf\" to \"false\" I also get the correct behavior\nof \"git blame\" - this is a workaround as long as I do not have to actually\nmodify anything.\n\nBest regards,\nFrank.\n"},{"id":"267648","messageId":"55C59A9B.9000808@web.de","threadId":"40032","inReplyTo":"B0BFE3BB9B3E8C4A890D53FA460552D3737328B0@DEWDFEMB16B.global.corp.sap","subject":"Re: git blame breaking on repository with CRLF files","fromName":"Torsten Bögershausen","fromEmail":"tboegi@web.de","sentAt":"2015-08-08T05:58:51Z","receivedAt":"2015-08-08T05:58:51Z","isPatch":false,"sender":{"key":"tboegi@web.de","avatar":"https://avatars.githubusercontent.com/u/7138363?v=4"},"body":"On 2015-08-07 18.32, Benkstein, Frank wrote:\n> Hello,\n> \n> I am working working on Linux and am examining code in a git repository I do\n> not know much about. I am only looking at files, not changing anything. On\n> some files in the repository I get \"00000000 (Not Committed Yet\" for all lines\n> when running \"git blame\". I checked with \"git status\", \"git reset\", \"git\n> clean\" that the files are indeed in the repository and unmodified. I noticed\n> that this only happens with git v2.5.0. With git v2.4.0 it looks correct, i.e.\n> the output has proper commit ids, Author names and dates.. With \"git bisect\" I\n> tracked this down to the following commit:\n> \n> commit 4bf256d67a85bed1e175ecc2706322eafe4489ca (HEAD, refs/bisect/bad)\n> Author: Torsten Bögershausen \n> Date: Sun May 3 18:38:01 2015 +0200\n> \n> blame: CRLF in the working tree and LF in the repo\n> \n> Digging further, it seems that most files in the repository are checked in with\n> CRLF line endings. In my working tree these are checked out as LF\nDo I understand it right that you have files in the repo with CRLF ?\nAnd these files are checked out with LF in the working tree ?\nAre the files marked with .gitattributes ?\nOr does the file have mixed line endings ?\n\n(Unless I missed something: Git never strips CRLF into LF at checkout,\nso I wonder how you ended up in this situation)\n\nIs there a way to reproduce it?\n\n - which\n> seems to be the exact opposite situation of what the commit is trying to\n> address. When I set \"core.autocrlf\" to \"false\" I also get the correct behavior\n> of \"git blame\" - this is a workaround as long as I do not have to actually\n> modify anything.\n> \n> Best regards,\n> Frank.\n"},{"id":"267697","messageId":"55C7B5EE.7060908@web.de","threadId":"40032","inReplyTo":"55C59A9B.9000808@web.de","subject":"Re: git blame breaking on repository with CRLF files","fromName":"Torsten Bögershausen","fromEmail":"tboegi@web.de","sentAt":"2015-08-09T20:19:58Z","receivedAt":"2015-08-09T20:19:58Z","isPatch":false,"sender":{"key":"tboegi@web.de","avatar":"https://avatars.githubusercontent.com/u/7138363?v=4"},"body":"On 2015-08-08 07.58, Torsten Bögershausen wrote:\n> On 2015-08-07 18.32, Benkstein, Frank wrote:\n>> Hello,\n>>\n>> I am working working on Linux and am examining code in a git repository I do\n>> not know much about. I am only looking at files, not changing anything. On\n>> some files in the repository I get \"00000000 (Not Committed Yet\" for all lines\n>> when running \"git blame\". I checked with \"git status\", \"git reset\", \"git\n>> clean\" that the files are indeed in the repository and unmodified. I noticed\n>> that this only happens with git v2.5.0. With git v2.4.0 it looks correct, i.e.\n>> the output has proper commit ids, Author names and dates.. With \"git bisect\" I\n>> tracked this down to the following commit:\n>>\n>> commit 4bf256d67a85bed1e175ecc2706322eafe4489ca (HEAD, refs/bisect/bad)\n>> Author: Torsten Bögershausen \n>> Date: Sun May 3 18:38:01 2015 +0200\n>>\n>> blame: CRLF in the working tree and LF in the repo\n>>\n>> Digging further, it seems that most files in the repository are checked in with\n>> CRLF line endings. In my working tree these are checked out as LF\n> Do I understand it right that you have files in the repo with CRLF ?\n> And these files are checked out with LF in the working tree ?\n> Are the files marked with .gitattributes ?\n> Or does the file have mixed line endings ?\n> \n> (Unless I missed something: Git never strips CRLF into LF at checkout,\n> so I wonder how you ended up in this situation)\n> \n> Is there a way to reproduce it?\n> \nActually I could reproduce the following:\nCRLF in repo, CRLF in working tree, core.autocrlf= true.\n\nThis is an old limitation (or call it bug), which has been there for a long\ntime, (I tested with Git v1.7.0 from 2010).\n\nThanks for the report, we will see if anybody is able to fix it.\nI can probably contribute some test cases.\n\n>> seems to be the exact opposite situation of what the commit is trying to\n>> address. When I set \"core.autocrlf\" to \"false\" I also get the correct behavior\n>> of \"git blame\" - this is a workaround as long as I do not have to actually\n>> modify anything.\n>>\n>> Best regards,\n>> Frank.\n"},{"id":"267705","messageId":"B0BFE3BB9B3E8C4A890D53FA460552D373734199@DEWDFEMB16B.global.corp.sap","threadId":"40032","inReplyTo":"55C7B5EE.7060908@web.de","subject":"RE: git blame breaking on repository with CRLF files","fromName":"Benkstein, Frank","fromEmail":"frank.benkstein@sap.com","sentAt":"2015-08-10T08:36:35Z","receivedAt":"2015-08-10T08:36:35Z","isPatch":false,"sender":{"key":"frank.benkstein@sap.com","avatar":null},"body":"Hello Torsten,\n\nTorsten Bögershausen, Sonntag, 9. August 2015 22:20:\n> On 2015-08-08 07.58, Torsten Bögershausen wrote:\n>> On 2015-08-07 18.32, Benkstein, Frank wrote:\n>>> I am working working on Linux and am examining code in a git repository I do\n>>> not know much about. I am only looking at files, not changing anything. On\n>>> some files in the repository I get \"00000000 (Not Committed Yet\" for all lines\n>>> when running \"git blame\". I checked with \"git status\", \"git reset\", \"git\n>>> clean\" that the files are indeed in the repository and unmodified. I noticed\n>>> that this only happens with git v2.5.0. With git v2.4.0 it looks correct, i.e.\n>>> the output has proper commit ids, Author names and dates.. With \"git bisect\" I\n>>> tracked this down to the following commit:\n>>>\n>>> commit 4bf256d67a85bed1e175ecc2706322eafe4489ca (HEAD, refs/bisect/bad)\n>>> Author: Torsten Bögershausen \n>>> Date: Sun May 3 18:38:01 2015 +0200\n>>>\n>>> blame: CRLF in the working tree and LF in the repo\n>>>\n>>> Digging further, it seems that most files in the repository are checked in with\n>>> CRLF line endings. In my working tree these are checked out as LF\n>> Do I understand it right that you have files in the repo with CRLF ?\n>> And these files are checked out with LF in the working tree ?\n>> Are the files marked with .gitattributes ?\n>> Or does the file have mixed line endings ?\n>> \n>> (Unless I missed something: Git never strips CRLF into LF at checkout,\n>> so I wonder how you ended up in this situation)\n\nYou were right. They are CRLF in my working tree. My editor tricked me.\n\n>> Is there a way to reproduce it?\n>> \n> Actually I could reproduce the following:\n> CRLF in repo, CRLF in working tree, core.autocrlf= true.\n> \n> This is an old limitation (or call it bug), which has been there for a long\n> time, (I tested with Git v1.7.0 from 2010).\n>\n> Thanks for the report, we will see if anybody is able to fix it.\n> I can probably contribute some test cases.\n\nYou are correct that it is also wrong in git v1.7.0. However, it is correct in\nv2.4.0.\n\nAnother bisect gave me this commit which was included in v2.0.1:\n\n commit 4d4813a52f3722854a54bab046f4abfec13ef6ae\n Author: brian m. carlson \n Date: Sat Apr 26 23:10:40 2014 +0000\n\n blame: correctly handle files regardless of autocrlf\n\nSo this still looks like a regression v2.5.0 to me.\n\nRegards,\nFrank.\n"},{"id":"267788","messageId":"xmqq1tfbugho.fsf@gitster.dls.corp.google.com","threadId":"40032","inReplyTo":"55C7B5EE.7060908@web.de","subject":"Re: git blame breaking on repository with CRLF files","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-08-10T18:48:35Z","receivedAt":"2015-08-10T18:48:35Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Torsten Bögershausen writes:\n\n> Actually I could reproduce the following:\n> CRLF in repo, CRLF in working tree, core.autocrlf= true.\n\nWhat should happen in such a case? Wouldn't autocrlf=true want to\nstrip CRLF down to LF? Shouldn't it? And if so, \"blame\" is correct\nto say that you are changing the line endings of all your lines, as\nwhat you _would_ commit if you were to commit the tracked files in\nyour working tree would be different from what is in the index, no?\n"},{"id":"267792","messageId":"55C9080C.6040704@web.de","threadId":"40032","inReplyTo":"xmqq1tfbugho.fsf@gitster.dls.corp.google.com","subject":"Re: git blame breaking on repository with CRLF files","fromName":"Torsten Bögershausen","fromEmail":"tboegi@web.de","sentAt":"2015-08-10T20:22:36Z","receivedAt":"2015-08-10T20:22:36Z","isPatch":false,"sender":{"key":"tboegi@web.de","avatar":"https://avatars.githubusercontent.com/u/7138363?v=4"},"body":"On 2015-08-10 20.48, Junio C Hamano wrote:\n> Torsten Bögershausen writes:\n> \n>> Actually I could reproduce the following:\n>> CRLF in repo, CRLF in working tree, core.autocrlf= true.\n> \n> What should happen in such a case? Wouldn't autocrlf=true want to\n> strip CRLF down to LF? Shouldn't it? \n\nA problem is, that \"git status\" would report a file as changed,\nwhen it have been committed with CRLF and core.autocrlf was false.\n\nThe only \"change\" that \"git status\" would trigger on would be the EOL normalization.\nSo if core.autocrlf would be set true later,\ngit status reports files as changed.....\n\nLong story short:\nOnce commited with CRLF, the files will not be normalized in a modern git:\n\nFrom convert.c:\nif (crlf_action == CRLF_GUESS) {\n\t/*\n\t * If the file in the index has any CR in it, do not convert.\n\t * This is the new safer autocrlf handling.\n\t */\n\tif (has_cr_in_index(path))\n\t\treturn 0;\n}\n---------------------\ncommit fd6cce9e89ab5ac1125a3b5f5611048ad22379e7\nAuthor: Eyvind Bernhardsen \nDate: Wed May 19 22:43:10 2010 +0200\n\n Add per-repository eol normalization\n\n Change the semantics of the \"crlf\" attribute so that it enables\n end-of-line normalization when it is set, regardless of \"core.autocrlf\".\n\n Add a new setting for \"crlf\": \"auto\", which enables end-of-line\n conversion but does not override the automatic text file detection.\n\n Add a new attribute \"eol\" with possible values \"crlf\" and \"lf\". When\n set, this attribute enables normalization and forces git to use CRLF or\n LF line endings in the working directory, respectively.\n\n The line ending style to be used for normalized text files in the\n working directory is set using \"core.autocrlf\". When it is set to\n \"true\", CRLFs are used in the working directory; when set to \"input\" or\n \"false\", LFs are used.\n-----------------\nSo \"git status\" is somewhat improved, but \"git blame\" is not.\n(My feeling/suspicion is that has_cr_in_index() should be replaced\nby has_cr_in_latest_commit() to have \"git status\" consistent\nwith \"git blame\", but more analyzes may be needed.)\n\nA different approach could be to ignore the EOL differences\ncompletely in \"git blame\" (when core.autocrlf is set and the file\nis text, or when the \"text\" attribute is set).\n\n\n> And if so, \"blame\" is correct\n> to say that you are changing the line endings of all your lines, as\n> what you _would_ commit if you were to commit the tracked files in\n> your working tree would be different from what is in the index, no?\n"},{"id":"267806","messageId":"20150810235403.GC9420@vauxhall.crustytoothpaste.net","threadId":"40032","inReplyTo":"B0BFE3BB9B3E8C4A890D53FA460552D373734199@DEWDFEMB16B.global.corp.sap","subject":"Re: git blame breaking on repository with CRLF files","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2015-08-10T23:54:03Z","receivedAt":"2015-08-10T23:54:03Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On Mon, Aug 10, 2015 at 08:36:35AM +0000, Benkstein, Frank wrote:\n> You are correct that it is also wrong in git v1.7.0. However, it is correct in\n> v2.4.0.\n> \n> Another bisect gave me this commit which was included in v2.0.1:\n> \n> commit 4d4813a52f3722854a54bab046f4abfec13ef6ae\n> Author: brian m. carlson \n> Date: Sat Apr 26 23:10:40 2014 +0000\n> \n> blame: correctly handle files regardless of autocrlf\n> \n> So this still looks like a regression v2.5.0 to me.\n\nThis commit was reverted because it was decided that it wasn't the right\nway to handle the problem and it broke other things. The complexity of\nthe CRLF handling is a bit beyond me, to be honest. I'm sure I'd\nunderstand it better if I used it more, but I'm a Unix guy.\n\nI stand by my earlier statement that we should improve the documentation\nin this area, because it's a common source of confusion.\n-- \nbrian m. carlson / brian with sandals: Houston, Texas, US\n+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only\nOpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187\n"}]}