{"thread":{"id":"39163","subject":"[PATCH/RFC] blame: CRLF in the working tree and LF in the repo","startedAt":"2015-04-26T12:02:34Z","lastAt":"2015-04-28T21:58:07Z","messageCount":16,"participants":["Torsten Bögershausen","Eric Sunshine","Stepan Kasal","Junio C Hamano","Johannes Sixt","brian m. carlson"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"260034","messageId":"553CD3DA.9090700@web.de","threadId":"39163","inReplyTo":null,"subject":"[PATCH/RFC] blame: CRLF in the working tree and LF in the repo","fromName":"Torsten Bögershausen","fromEmail":"tboegi@web.de","sentAt":"2015-04-26T12:02:34Z","receivedAt":"2015-04-26T12:02:34Z","isPatch":true,"sender":{"key":"tboegi@web.de","avatar":"https://avatars.githubusercontent.com/u/7138363?v=4"},"body":"A typicall setup under Windows:\ncore.eol is CRLF and a file is marked as \"text\" in .gitattributes.\n\nAfter 4d4813a5 \"git blame\" no longer works as expected,\nevery line is annotated as \"Not Committed Yet\",\neven though the working directory is clean.\n\ncommit 4d4813a5 removed the conversion in blame.c for all files,\nwith or without CRLF in the repo.\n\nHaving files with CRLF in the repo and core.autocrlf=input is a temporary\nsituation, the files should be normalized in the repo.\nBlaming them with \"Not Committed Yet\" is OK.\n\nThe solution is to revert commit 4d4813a5.\n\nReported-By: Stepan Kasal \nSigned-off-by: Torsten Bögershausen \n---\nReference:\nhttps://github.com/git-for-windows/git/issues/105\nAlthough the intention of 4d4813a5 is good, it breaks\nthe usual EOL-handling for Windows.\nUntil we have a better solution, we suggest to revert it.\n\n builtin/blame.c | 1 +\n t/t8003-blame-corner-cases.sh | 26 +++++++++++++++++++++++++-\n 2 files changed, 26 insertions(+), 1 deletion(-)\n\ndiff --git a/builtin/blame.c b/builtin/blame.c\nindex 06484c2..8d70623 100644\n--- a/builtin/blame.c\n+++ b/builtin/blame.c\n@@ -2348,6 +2348,7 @@ static struct commit *fake_working_tree_commit(struct diff_options *opt,\n \t\tif (strbuf_read(&buf, 0, 0) < 0)\n \t\t\tdie_errno(\"failed to read from stdin\");\n \t}\n+\tconvert_to_git(path, buf.buf, buf.len, &buf, 0);\n \torigin->file.ptr = buf.buf;\n \torigin->file.size = buf.len;\n \tpretend_sha1_file(buf.buf, buf.len, OBJ_BLOB, origin->blob_sha1);\ndiff --git a/t/t8003-blame-corner-cases.sh b/t/t8003-blame-corner-cases.sh\nindex 32895e5..dcc9827 100755\n--- a/t/t8003-blame-corner-cases.sh\n+++ b/t/t8003-blame-corner-cases.sh\n@@ -191,7 +191,7 @@ test_expect_success 'indent of line numbers, ten lines' '\n \ttest $(grep -c \" \" actual) = 9\n '\n \n-test_expect_success 'blaming files with CRLF newlines' '\n+test_expect_failure 'blaming files with CRLF newlines in repo, core.autoclrf=input' '\n \tgit config core.autocrlf false &&\n \tprintf \"testcase\\r\\n\" >crlffile &&\n \tgit add crlffile &&\n@@ -199,5 +199,29 @@ test_expect_success 'blaming files with CRLF newlines' '\n \tgit -c core.autocrlf=input blame crlffile >actual &&\n \tgrep \"A U Thor\" actual\n '\n+test_expect_success 'blaming files with CRLF newlines core.autocrlf=true' '\n+\ttest_create_repo blamerepo &&\n+\t(\n+\t\tcd blamerepo &&\n+\t\tgit config core.autocrlf true &&\n+\t\tprintf \"testcase\\r\\n\" >crlffile &&\n+\t\tgit add crlffile &&\n+\t\tgit commit -m TRUE &&\n+\t\tgit blame crlffile >actual &&\n+\t\tgrep \"A U Thor\" actual\n+\t)\n+'\n+\n+test_expect_success 'blaming files with CRLF newlines core.autocrlf=false' '\n+\t(\n+\t\tcd blamerepo &&\n+\t\tgit config core.autocrlf false &&\n+\t\tprintf \".gitattributes text\\r\\n\" >.gitattributes &&\n+\t\tgit add .gitattributes &&\n+\t\tgit commit -m FALSE &&\n+\t\tgit blame .gitattributes >actual &&\n+\t\tgrep \"A U Thor\" actual\n+\t)\n+'\n \n test_done\n-- \n2.2.0.rc1.790.ge19fcd2\n"},{"id":"260036","messageId":"CAPig+cT3rpEFVerjxA9vCXh0wFdmwBhDEnvgk1hBumsSAtDcVw@mail.gmail.com","threadId":"39163","inReplyTo":"553CD3DA.9090700@web.de","subject":"Re: [PATCH/RFC] blame: CRLF in the working tree and LF in the repo","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2015-04-26T18:36:00Z","receivedAt":"2015-04-26T18:36:00Z","isPatch":true,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Sun, Apr 26, 2015 at 8:02 AM, Torsten Bögershausen wrote:\n> A typicall setup under Windows:\n\ns/typicall/typical/\n\n> core.eol is CRLF and a file is marked as \"text\" in .gitattributes.\n>\n> After 4d4813a5 \"git blame\" no longer works as expected,\n> every line is annotated as \"Not Committed Yet\",\n> even though the working directory is clean.\n>\n> commit 4d4813a5 removed the conversion in blame.c for all files,\n> with or without CRLF in the repo.\n>\n> Having files with CRLF in the repo and core.autocrlf=input is a temporary\n> situation, the files should be normalized in the repo.\n> Blaming them with \"Not Committed Yet\" is OK.\n>\n> The solution is to revert commit 4d4813a5.\n>\n> Reported-By: Stepan Kasal \n> Signed-off-by: Torsten Bögershausen \n"},{"id":"260048","messageId":"20150427043900.GC1578@camelia.ucw.cz","threadId":"39163","inReplyTo":"553CD3DA.9090700@web.de","subject":"Re: [PATCH/RFC] blame: CRLF in the working tree and LF in the repo","fromName":"Stepan Kasal","fromEmail":"kasal@ucw.cz","sentAt":"2015-04-27T04:39:00Z","receivedAt":"2015-04-27T04:39:00Z","isPatch":true,"sender":{"key":"kasal@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/1481596?v=4"},"body":"Hello,\n\nthank you Torsten for the patch [I'm the reporter, but could not do\nit myself]\n\n> -test_expect_success 'blaming files with CRLF newlines' '\n> +test_expect_failure 'blaming files with CRLF newlines in repo, core.autoclrf=input' '\n\nShouldn't the old test be rather removed?\nIt deals with an invalid situation.\n\nI thought that having crlf in the repo is incorrect, so no wonder\nthat it fails if the files in the working tree are changed to LF.\n\nAnd changing the autocrlf transformation is effectively the same,\nno matter that the files _physically_ are the same as the files in\nthe repo.\n\nHave a nice day,\n Stepan Kasal\n"},{"id":"260049","messageId":"xmqqzj5uxhls.fsf@gitster.dls.corp.google.com","threadId":"39163","inReplyTo":"553CD3DA.9090700@web.de","subject":"Re: [PATCH/RFC] blame: CRLF in the working tree and LF in the repo","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-04-27T05:31:11Z","receivedAt":"2015-04-27T05:31:11Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Torsten Bögershausen writes:\n\n> Although the intention of 4d4813a5 is good, it breaks\n> the usual EOL-handling for Windows.\n> Until we have a better solution, we suggest to revert it.\n\nThat makes it sound like you are proposing to rob Peter to pay Paul,\nbut that is not how we do things around here. If both the case\n4d4813a5 tried to solve and the issue reported by Stepan need to be\nsatisfied, the current code will stay as-is until you can find a\ngood solution to make both happy.\n\nHaving said that.\n\nI suspect (I haven't looked very carefully for this round yet to be\nsure, though) that it may turn out that the commit you are proposing\nto revert was a misguided attempt to \"fix\" a non issue, or to break\nthe behaviour to match a mistaken expectation. If that is the case\nthen definitely the reversion is a good idea, and you should argue\nalong that line of justification.\n\nWe'd just be fixing an old misguided and bad change in such a case.\n\nThanks.\n"},{"id":"260050","messageId":"20150427061115.GB2766@camelia.ucw.cz","threadId":"39163","inReplyTo":"xmqqzj5uxhls.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH/RFC] blame: CRLF in the working tree and LF in the repo","fromName":"Stepan Kasal","fromEmail":"kasal@ucw.cz","sentAt":"2015-04-27T06:11:16Z","receivedAt":"2015-04-27T06:11:16Z","isPatch":true,"sender":{"key":"kasal@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/1481596?v=4"},"body":"Hello,\n\nOn Sun, Apr 26, 2015 at 10:31:11PM -0700, Junio C Hamano wrote:\n> [...] the commit you are proposing to revert [4d4813a5]\n> was a misguided attempt to \"fix\" a non issue, [...]\n\nyes, it was this. So I propose to remove the whole commit,\nincluding the test case and add two new test cases.\n\nDetails:\n\nGit does not support CRLF as the internal line separator.\nIf you commit file in binary mode with CRLF, you are on your own.\n\nIf you then recode the file in the working tree to use LF, no wonder\nthings break.\n\nIf you do it indirectly, by setting the file mode to \"text\", things\nbreak exactly the same way.\n\nAnd that is the case that 4d4813a5 wanted to fix, cf the test case\nin it.\n\nOTOH, the commit has broken the most recommended scenario for Windows:\nLF in the repo, CRLF in the work tree.\n\nThanks,\n\tStepan\n"},{"id":"260061","messageId":"xmqqa8xtxy32.fsf@gitster.dls.corp.google.com","threadId":"39163","inReplyTo":"xmqqzj5uxhls.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH/RFC] blame: CRLF in the working tree and LF in the repo","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-04-27T17:47:29Z","receivedAt":"2015-04-27T17:47:29Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> I suspect (I haven't looked very carefully for this round yet to be\n> sure, though) that it may turn out that the commit you are proposing\n> to revert was a misguided attempt to \"fix\" a non issue, or to break\n> the behaviour to match a mistaken expectation. If that is the case\n> then definitely the reversion is a good idea, and you should argue\n> along that line of justification.\n>\n> We'd just be fixing an old misguided and bad change in such a case.\n\nThe original says this:\n\n blame: correctly handle files regardless of autocrlf\n \n If a file contained CRLF line endings in a repository with\n core.autocrlf=input, then blame always marked lines as \"Not\n Committed Yet\", even if they were unmodified. Don't attempt to\n convert the line endings when creating the fake commit so that blame\n works correctly regardless of the autocrlf setting.\n \n Reported-by: Ephrim Khong \n Signed-off-by: brian m. carlson \n Signed-off-by: Junio C Hamano \n\nBut if autocrlf=input, then the end-user expectation is to keep the\nin-repository data with LF line endings. If your tip-of-the-tree\ncommit incorrectly has CRLF line endings, and if you were going to\ncommit what is in the working tree on top, you would be correcting\nthat mistake by turning the in-repository data into a text file with\nLF line endings, so \"Not Committed Yet\" _is_ the correct behaviour.\n\nSo I think that the reverting that change is the right thing to do.\nIt really was a change to break the behaviour to match a mistaken\nexpectation, I would have to say.\n"},{"id":"260073","messageId":"553E86BD.7030401@kdbg.org","threadId":"39163","inReplyTo":"20150427061115.GB2766@camelia.ucw.cz","subject":"Re: [PATCH/RFC] blame: CRLF in the working tree and LF in the repo","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2015-04-27T18:58:05Z","receivedAt":"2015-04-27T18:58:05Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 27.04.2015 um 08:11 schrieb Stepan Kasal:\n> Git does not support CRLF as the internal line separator.\n> If you commit file in binary mode with CRLF, you are on your own.\n\nWhen I commit my C source code files with CRLF into the repository \n(because I do not set any line ending options or configurations or any \n'text' attributes or similar), do I then commit binary files or text \nfiles? Should I expect not to see any diffs?\n\n-- Hannes\n"},{"id":"260078","messageId":"553E90C0.4070103@web.de","threadId":"39163","inReplyTo":"xmqqa8xtxy32.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH/RFC] blame: CRLF in the working tree and LF in the repo","fromName":"Torsten Bögershausen","fromEmail":"tboegi@web.de","sentAt":"2015-04-27T19:40:48Z","receivedAt":"2015-04-27T19:40:48Z","isPatch":true,"sender":{"key":"tboegi@web.de","avatar":"https://avatars.githubusercontent.com/u/7138363?v=4"},"body":"On 04/27/2015 07:47 PM, Junio C Hamano wrote:\n> Junio C Hamano writes:\n>\n>> I suspect (I haven't looked very carefully for this round yet to be\n>> sure, though) that it may turn out that the commit you are proposing\n>> to revert was a misguided attempt to \"fix\" a non issue, or to break\n>> the behaviour to match a mistaken expectation. If that is the case\n>> then definitely the reversion is a good idea, and you should argue\n>> along that line of justification.\n>>\n>> We'd just be fixing an old misguided and bad change in such a case.\n> The original says this:\n>\n> blame: correctly handle files regardless of autocrlf\n> \n> If a file contained CRLF line endings in a repository with\n> core.autocrlf=input, then blame always marked lines as \"Not\n> Committed Yet\", even if they were unmodified. Don't attempt to\n> convert the line endings when creating the fake commit so that blame\n> works correctly regardless of the autocrlf setting.\n> \n> Reported-by: Ephrim Khong \n> Signed-off-by: brian m. carlson \n> Signed-off-by: Junio C Hamano \n>\n> But if autocrlf=input, then the end-user expectation is to keep the\n> in-repository data with LF line endings. If your tip-of-the-tree\n> commit incorrectly has CRLF line endings, and if you were going to\n> commit what is in the working tree on top, you would be correcting\n> that mistake by turning the in-repository data into a text file with\n> LF line endings, so \"Not Committed Yet\" _is_ the correct behaviour.\n>\n> So I think that the reverting that change is the right thing to do.\n> It really was a change to break the behaviour to match a mistaken\n> expectation, I would have to say.\nBesides a better commit message (suggestions welcome),\nWhat do you think about the following test cases for a V2 patch ?\n\ntest_expect_success 'create blamerepo' '\n test_create_repo blamerepo &&\n (\n cd blamerepo &&\n printf \"testcase\\r\\n\" >crlffile &&\n git -c core.autocrlf=false add crlffile &&\n git commit -m \"add files\" &&\n git -c core.autocrlf=false blame crlffile >crlfclean.txt\n )\n'\n\ntest_expect_success 'blaming files with CRLF newlines in repo, core.autoclrf=input' '\n (\n cd blamerepo &&\n git -c core.autocrlf=input blame crlffile >actual &&\n grep \"Not Committed Yet\" actual\n )\n'\n\n\ntest_expect_success 'blaming files with CRLF newlines core.autocrlf=true' '\n (\n cd blamerepo &&\n git -c core.autocrlf=true blame crlffile >actual &&\n test_cmp crlfclean.txt actual\n )\n'\n\ntest_expect_success 'blaming files with CRLF newlines core.autocrlf=false' '\n (\n cd blamerepo &&\n git -c core.autocrlf=false blame crlffile >actual &&\n test_cmp crlfclean.txt actual\n )\n'\n"},{"id":"260079","messageId":"553E91CD.9060205@web.de","threadId":"39163","inReplyTo":"553E86BD.7030401@kdbg.org","subject":"Re: [PATCH/RFC] blame: CRLF in the working tree and LF in the repo","fromName":"Torsten Bögershausen","fromEmail":"tboegi@web.de","sentAt":"2015-04-27T19:45:17Z","receivedAt":"2015-04-27T19:45:17Z","isPatch":true,"sender":{"key":"tboegi@web.de","avatar":"https://avatars.githubusercontent.com/u/7138363?v=4"},"body":"On 04/27/2015 08:58 PM, Johannes Sixt wrote:\n> Am 27.04.2015 um 08:11 schrieb Stepan Kasal:\n>> Git does not support CRLF as the internal line separator.\n>> If you commit file in binary mode with CRLF, you are on your own.\n> \n> When I commit my C source code files with CRLF into the repository (because I do not set any line ending options or configurations or any 'text' attributes or similar), do I then commit binary files or text files? Should I expect not to see any diffs?\n> \n> -- Hannes\n> \nYou commit files with CRLF in the repo.\nIf you have CRLF in the working tree, things are as follows:\n\ncore.autocrlf=false : \"Same as binary, no changes\"\ncore.autocrlf=true : \"Normalization is suppressed, (CRLF in repo), and therefore no changes.\ncore.autocrlf=input : \"Normalization wanted, (CRLF in repo), normalization will be done\n (and should be committed as soon as possible)\n \n"},{"id":"260090","messageId":"20150428011702.GA5015@vauxhall.crustytoothpaste.net","threadId":"39163","inReplyTo":"xmqqa8xtxy32.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH/RFC] blame: CRLF in the working tree and LF in the repo","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2015-04-28T01:17:03Z","receivedAt":"2015-04-28T01:17:03Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On Mon, Apr 27, 2015 at 10:47:29AM -0700, Junio C Hamano wrote:\n> The original says this:\n> \n> blame: correctly handle files regardless of autocrlf\n> \n> If a file contained CRLF line endings in a repository with\n> core.autocrlf=input, then blame always marked lines as \"Not\n> Committed Yet\", even if they were unmodified. Don't attempt to\n> convert the line endings when creating the fake commit so that blame\n> works correctly regardless of the autocrlf setting.\n> \n> Reported-by: Ephrim Khong \n> Signed-off-by: brian m. carlson \n> Signed-off-by: Junio C Hamano \n> \n> But if autocrlf=input, then the end-user expectation is to keep the\n> in-repository data with LF line endings. If your tip-of-the-tree\n> commit incorrectly has CRLF line endings, and if you were going to\n> commit what is in the working tree on top, you would be correcting\n> that mistake by turning the in-repository data into a text file with\n> LF line endings, so \"Not Committed Yet\" _is_ the correct behaviour.\n> \n> So I think that the reverting that change is the right thing to do.\n> It really was a change to break the behaviour to match a mistaken\n> expectation, I would have to say.\n\nI don't have a strong opinion on whether or not this should be reverted,\nsince I don't use Windows and therefore don't use CRLF or the respective\noptions anywhere, nor am I very familiar with how they are supposed to\nfunction. Junio has articulated a good rationale for why it's broken,\nand I'm willing to go along with that.\n\nI will say that perhaps it's worthwhile to write some documentation to\nexplain how the CRLF translation works, as it seems that there's a lot\nof misunderstanding about it. I am, for the aforementioned reasons, not\na good choice to write it.\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"},{"id":"260113","messageId":"xmqqbni8vhiz.fsf@gitster.dls.corp.google.com","threadId":"39163","inReplyTo":"553E90C0.4070103@web.de","subject":"Re: [PATCH/RFC] blame: CRLF in the working tree and LF in the repo","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-04-28T07:28:04Z","receivedAt":"2015-04-28T07:28:04Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Torsten Bögershausen writes:\n\n> What do you think about the following test cases for a V2 patch ?\n>\n> test_expect_success 'create blamerepo' '\n> test_create_repo blamerepo &&\n> (\n> cd blamerepo &&\n> printf \"testcase\\r\\n\" >crlffile &&\n> git -c core.autocrlf=false add crlffile &&\n> git commit -m \"add files\" &&\n> git -c core.autocrlf=false blame crlffile >crlfclean.txt\n> )\n> '\n>\n> test_expect_success 'blaming files with CRLF newlines in repo, core.autoclrf=input' '\n> (\n> cd blamerepo &&\n> git -c core.autocrlf=input blame crlffile >actual &&\n> grep \"Not Committed Yet\" actual\n\nAre you interested in seeing just some of the lines to show up as\n\"Not commited yet\", or all of them? I think it would be the latter,\nso perhaps \n\n ! grep -v \"Not Committed Yet\" actual\n\nor something?\n\n> )\n> '\n>\n>\n\nTwo blank lines only here?\n\n> test_expect_success 'blaming files with CRLF newlines core.autocrlf=true' '\n> (\n> cd blamerepo &&\n> git -c core.autocrlf=true blame crlffile >actual &&\n> test_cmp crlfclean.txt actual\n> )\n> '\n\nOK\n\n> test_expect_success 'blaming files with CRLF newlines core.autocrlf=false' '\n> (\n> cd blamerepo &&\n> git -c core.autocrlf=false blame crlffile >actual &&\n> test_cmp crlfclean.txt actual\n> )\n> '\n\nHmm, how's this blame invocation any different from the one done in\nthe set-up step at the very beginning? In other words, I am not sure\nwhat kind of breakage could cause this step to fail.\n\nI see there is no \"git blame HEAD crlffile\" that bypasses the fake\nlatest commit altogether. Wouldn't that be the most appropriate\nthing to compare against (i.e. how to create crlfclean.txt in the\nset-up step)?\n"},{"id":"260114","messageId":"553F3959.1060202@web.de","threadId":"39163","inReplyTo":"xmqqbni8vhiz.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH/RFC] blame: CRLF in the working tree and LF in the repo","fromName":"Torsten Bögershausen","fromEmail":"tboegi@web.de","sentAt":"2015-04-28T07:40:09Z","receivedAt":"2015-04-28T07:40:09Z","isPatch":true,"sender":{"key":"tboegi@web.de","avatar":"https://avatars.githubusercontent.com/u/7138363?v=4"},"body":"\n\nOn 28/04/15 09:28, Junio C Hamano wrote:\n> Torsten Bögershausen writes:\n>\n>> What do you think about the following test cases for a V2 patch ?\n>>\n>> test_expect_success 'create blamerepo' '\n>> test_create_repo blamerepo &&\n>> (\n>> cd blamerepo &&\n>> printf \"testcase\\r\\n\" >crlffile &&\n>> git -c core.autocrlf=false add crlffile &&\n>> git commit -m \"add files\" &&\n>> git -c core.autocrlf=false blame crlffile >crlfclean.txt\n>> )\n>> '\n>>\n>> test_expect_success 'blaming files with CRLF newlines in repo, core.autoclrf=input' '\n>> (\n>> cd blamerepo &&\n>> git -c core.autocrlf=input blame crlffile >actual &&\n>> grep \"Not Committed Yet\" actual\n> Are you interested in seeing just some of the lines to show up as\n> \"Not commited yet\", or all of them? I think it would be the latter,\n> so perhaps\n>\n> ! grep -v \"Not Committed Yet\" actual\n>\n> or something?\n>\n>> )\n>> '\n>>\n>>\n> Two blank lines only here?\n>\n>> test_expect_success 'blaming files with CRLF newlines core.autocrlf=true' '\n>> (\n>> cd blamerepo &&\n>> git -c core.autocrlf=true blame crlffile >actual &&\n>> test_cmp crlfclean.txt actual\n>> )\n>> '\n> OK\nInterestingly this test doesn't pass on one of my systems,\nafter having stripped t8003 to contain to only have the corner cases.\nWhen core.autocrlf is true, the converting should be suppressed:\n convert.c/has_cr_in_index() should return 1, but doesn't.\n\n data = read_blob_data_from_cache(path, &sz);\nand data is NULL.\n\nSome more digging has to be done here.\n\nOn the other hand we want to test blame on a file with LF in the\nrepo and CRLF in the workspace as well.\n\nSo all in all I need to send a V2.\n\n\n\n\n\n>\n>> test_expect_success 'blaming files with CRLF newlines core.autocrlf=false' '\n>> (\n>> cd blamerepo &&\n>> git -c core.autocrlf=false blame crlffile >actual &&\n>> test_cmp crlfclean.txt actual\n>> )\n>> '\n> Hmm, how's this blame invocation any different from the one done in\n> the set-up step at the very beginning? In other words, I am not sure\n> what kind of breakage could cause this step to fail.\n>\n> I see there is no \"git blame HEAD crlffile\" that bypasses the fake\n> latest commit altogether. Wouldn't that be the most appropriate\n> thing to compare against (i.e. how to create crlfclean.txt in the\n> set-up step)?\n>\nJepp,\n\nThere is room for improvements.\n"},{"id":"260134","messageId":"553FD48B.1010608@kdbg.org","threadId":"39163","inReplyTo":"553E91CD.9060205@web.de","subject":"Re: [PATCH/RFC] blame: CRLF in the working tree and LF in the repo","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2015-04-28T18:42:19Z","receivedAt":"2015-04-28T18:42:19Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 27.04.2015 um 21:45 schrieb Torsten Bögershausen:\n> On 04/27/2015 08:58 PM, Johannes Sixt wrote:\n>> Am 27.04.2015 um 08:11 schrieb Stepan Kasal:\n>>> Git does not support CRLF as the internal line separator.\n>>> If you commit file in binary mode with CRLF, you are on your own.\n>>\n>> When I commit my C source code files with CRLF into the repository\n>> (because I do not set any line ending options or configurations or any\n>> 'text' attributes or similar), do I then commit binary files or text\n>> files? Should I expect not to see any diffs?\n>>\n>> -- Hannes\n>>\n> You commit files with CRLF in the repo.\n> If you have CRLF in the working tree, things are as follows:\n>\n> core.autocrlf=false : \"Same as binary, no changes\"\n> core.autocrlf=true : \"Normalization is suppressed, (CRLF in repo), and therefore no changes.\n> core.autocrlf=input : \"Normalization wanted, (CRLF in repo), normalization will be done\n> (and should be committed as soon as possible)\n\nI set none of these. But I do commit CRLF and expect to get CRLF back. \nAm I commiting binary files? Am I doing something that \"Git does not \nsupport\"? Am I \"on [my] own\"?\n\n-- Hannes\n"},{"id":"260138","messageId":"xmqq7fswuj1s.fsf@gitster.dls.corp.google.com","threadId":"39163","inReplyTo":"553FD48B.1010608@kdbg.org","subject":"Re: [PATCH/RFC] blame: CRLF in the working tree and LF in the repo","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-04-28T19:52:47Z","receivedAt":"2015-04-28T19:52:47Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Sixt writes:\n\n> I set none of these. But I do commit CRLF and expect to get CRLF\n> back. Am I commiting binary files? Am I doing something that \"Git does\n> not support\"? Am I \"on [my] own\"?\n\nI think these specific sentences are merely uninformed opinions; if\nI ignore and re-read what people said in the discussion, I think the\nthread as a whole makes sense.\n"},{"id":"260141","messageId":"553FEB4F.7050409@kdbg.org","threadId":"39163","inReplyTo":"xmqq7fswuj1s.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH/RFC] blame: CRLF in the working tree and LF in the repo","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2015-04-28T20:19:27Z","receivedAt":"2015-04-28T20:19:27Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 28.04.2015 um 21:52 schrieb Junio C Hamano:\n> Johannes Sixt writes:\n>\n>> I set none of these. But I do commit CRLF and expect to get CRLF\n>> back. Am I commiting binary files? Am I doing something that \"Git does\n>> not support\"? Am I \"on [my] own\"?\n>\n> I think these specific sentences are merely uninformed opinions; if\n> I ignore and re-read what people said in the discussion, I think the\n> thread as a whole makes sense.\n\nThanks for the clarification. Following the thread only superficially, I \nfeared some behavior change (or even just a redefinition of what \"is \nsupported\") is about to surface that impacts established workflows.\n\n-- Hannes\n"},{"id":"260148","messageId":"20150428215807.GE1433@camelia.ucw.cz","threadId":"39163","inReplyTo":"553FEB4F.7050409@kdbg.org","subject":"Re: [PATCH/RFC] blame: CRLF in the working tree and LF in the repo","fromName":"Stepan Kasal","fromEmail":"kasal@ucw.cz","sentAt":"2015-04-28T21:58:07Z","receivedAt":"2015-04-28T21:58:07Z","isPatch":true,"sender":{"key":"kasal@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/1481596?v=4"},"body":"Hello Hannes,\n\nlet me correct my previous statement:\n\nOn Mon, Apr 27, 2015 at 08:58:05PM +0200, Johannes Sixt wrote:\n> When I commit my C source code files with CRLF into the repository \n> (because I do not set any line ending options or configurations or any \n> 'text' attributes or similar), do I then commit binary files or text \n> files? Should I expect not to see any diffs?\n\nOf course, you can see diffs. The files are not binary in that\nsense.\n\nJohannes Sixt writes:\n> I set none of these. But I do commit CRLF and expect to get CRLF\n> back. [...]\n\nThat works. You will not encounter any problem. (Supposing you\ndo not change the line ending options, of course.)\n\nFinally, let me explain my previous statement:\n> Am 27.04.2015 um 08:11 schrieb Stepan Kasal:\n>> Git does not support CRLF as the internal line separator.\n\nI'm often asked: \"How do I set up git so that it uses CRLF in text\nfiles in the repository and checks them out with CRLF on Windows and\nwith LF on unixy systems?\"\n\nMy answer to that question always was that you cannot configure the\ninternal line separator in git repo, it is always LF. Your only\nchance to support both line endings is to have LF in the repo and\nconfigure the Windows client to do the conversion.\n\n>> If you commit file in binary mode with CRLF, you are on your own.\n\nOK, scratch the word \"binary\". The files in the repo are actually\ntext files. But each text line is contains one more char than you\nwould think. From time to time, this lurks:\n\n1) Does \"git grep ';$' HEAD\" find anything?\n2) What about \"git grep ';.$' HEAD\" ?\n Or \"git grep `printf ';\\r$' HEAD\" ?\n\n3) If you try things like\n git diff HEAD^^..HEAD^ >outfile.diff\n and then open outfile.diff with a suitable editor (e.g. vim), you\n can see an extra ^M at the end of some lines (the content ones).\n\nThis is why I tell users that they are on their own if they decide to\nuse the setup you described.\n\nHave a nice day,\n\tStepan\n"}]}