{"thread":{"id":"51605","subject":"suggestion for improved docs on autocrlf","startedAt":"2019-08-07T13:20:16Z","lastAt":"2019-08-16T19:12:54Z","messageCount":23,"participants":["Yagnatinsky, Mark","Torsten Bögershausen","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"380072","messageId":"9c79d35e48df4d28baf995ad3f5b0153@bofa.com","threadId":"51605","inReplyTo":null,"subject":"suggestion for improved docs on autocrlf","fromName":"Yagnatinsky, Mark","fromEmail":"mark.yagnatinsky@bofa.com","sentAt":"2019-08-07T13:08:22Z","receivedAt":"2019-08-07T13:20:16Z","isPatch":false,"sender":{"key":"mark.yagnatinsky@bofa.com","avatar":null},"body":"I hope this is the right mailing list, hope someone will redirect me if not...\nThe git documentation (git help config) for core.autocrlf doesn't mention that false is a valid option; it only mentions true and input.\nFurther, the docs for \"input\" are misleading, in that they lead the reader to assume it behaves like \"false\".\n\nWould probably be nice if this were fixed :)\nMark.\n\n----------------------------------------------------------------------\nThis message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer. If you are not the intended recipient, please delete this message.\n"},{"id":"380171","messageId":"20190808205631.e2647kxq74thotjb@tb-raspi4","threadId":"51605","inReplyTo":"9c79d35e48df4d28baf995ad3f5b0153@bofa.com","subject":"Re: suggestion for improved docs on autocrlf","fromName":"Torsten Bögershausen","fromEmail":"tboegi@web.de","sentAt":"2019-08-08T20:56:31Z","receivedAt":"2019-08-08T20:56:39Z","isPatch":false,"sender":{"key":"tboegi@web.de","avatar":"https://avatars.githubusercontent.com/u/7138363?v=4"},"body":"On Wed, Aug 07, 2019 at 01:08:22PM +0000, Yagnatinsky, Mark wrote:\n> I hope this is the right mailing list, hope someone will redirect me if not...\n\nYes, you are at the right place, wellcome to the Git community.\n\n> The git documentation (git help config) for core.autocrlf doesn't mention that false is a valid option; it only mentions true and input.\n\nThis is somewhat common to all config settings:\nWHen a new feature is introduced, Git treats \"config not defined\" as false.\nThis allows later Git versions to behave like older versions,\nwhen the config is not set.\nIn that sense \"not set\" means the same as \"false\", and is the opposite to \"true\".\n(At least for core.autocrlf).\n\nLater the third value \"input\" was introduced.\n\n> Further, the docs for \"input\" are misleading, in that they lead the reader to assume it behaves like \"false\".\n>\nWe can agree on that.\n\n> Would probably be nice if this were fixed :)\n\nYes, do I read this as \"I will send a patch\" ?\nThat would be nice.\n\n> Mark.\n"},{"id":"380173","messageId":"3269668c03a8482d8d854ec19dd43907@bofa.com","threadId":"51605","inReplyTo":"20190808205631.e2647kxq74thotjb@tb-raspi4","subject":"RE: suggestion for improved docs on autocrlf","fromName":"Yagnatinsky, Mark","fromEmail":"mark.yagnatinsky@bofa.com","sentAt":"2019-08-08T21:19:30Z","receivedAt":"2019-08-08T21:19:36Z","isPatch":false,"sender":{"key":"mark.yagnatinsky@bofa.com","avatar":null},"body":"> Yes, do I read this as \"I will send a patch\" ?\nProbably not, but you can read it as \"I will cook up better wording and reply to this thread\"\n\n----------------------------------------------------------------------\nThis message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer. If you are not the intended recipient, please delete this message.\n"},{"id":"380182","messageId":"577a66e0c26545aaa4795de3c5189c9d@bofa.com","threadId":"51605","inReplyTo":"3269668c03a8482d8d854ec19dd43907@bofa.com","subject":"RE: suggestion for improved docs on autocrlf","fromName":"Yagnatinsky, Mark","fromEmail":"mark.yagnatinsky@bofa.com","sentAt":"2019-08-08T23:08:14Z","receivedAt":"2019-08-08T23:08:27Z","isPatch":false,"sender":{"key":"mark.yagnatinsky@bofa.com","avatar":null},"body":"Okay, my attempt at better wording for the docs is not going well, because it turns I that I still don't understand the behavior here!\nI thought that \"input\" means that CRLF will become LF on \"git add\" but that seems to be true only sometimes.\nFor instance, consider the following 11-line shell script:\n\nmkdir empty\ncd empty\ngit init\ngit config core.autocrlf false\necho -e '1\\r\\n2' > test.txt\ngit add .\ngit commit -m test\ngit config core.autocrlf input\ncp test.txt t2.txt\necho 'a\\r\\nb' > test.txt\ngit add .\n\nThe output from the last git add is:\n\nwarning: CRLF will be replaced by LF in t2.txt.\nThe file will have its original line endings in your working directory.\n\nWhich is a very good warning indeed, but why does it only apply to the new file t2.txt?\nWhy does the existing file test.txt retain its CRLF line endings.\n\nI am so confused.\n\nAny pointers?\n\n----------------------------------------------------------------------\nThis message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer. If you are not the intended recipient, please delete this message.\n"},{"id":"380197","messageId":"20190809033406.5t5ag3qmh36ideec@tb-raspi4","threadId":"51605","inReplyTo":"577a66e0c26545aaa4795de3c5189c9d@bofa.com","subject":"Re: suggestion for improved docs on autocrlf","fromName":"Torsten Bögershausen","fromEmail":"tboegi@web.de","sentAt":"2019-08-09T03:34:06Z","receivedAt":"2019-08-09T03:34:14Z","isPatch":false,"sender":{"key":"tboegi@web.de","avatar":"https://avatars.githubusercontent.com/u/7138363?v=4"},"body":"On Thu, Aug 08, 2019 at 11:08:14PM +0000, Yagnatinsky, Mark wrote:\n> Okay, my attempt at better wording for the docs is not going well, because it turns I that I still don't understand the behavior here!\n> I thought that \"input\" means that CRLF will become LF on \"git add\" but that seems to be true only sometimes.\n> For instance, consider the following 11-line shell script:\n>\n> mkdir empty\n> cd empty\n> git init\n> git config core.autocrlf false\n> echo -e '1\\r\\n2' > test.txt\n> git add .\n> git commit -m test\n> git config core.autocrlf input\n> cp test.txt t2.txt\n> echo 'a\\r\\nb' > test.txt\n> git add .\n>\n> The output from the last git add is:\n>\n> warning: CRLF will be replaced by LF in t2.txt.\n> The file will have its original line endings in your working directory.\n>\n> Which is a very good warning indeed, but why does it only apply to the new file t2.txt?\n> Why does the existing file test.txt retain its CRLF line endings.\nBecause there are no CRLF ;-)\n\nThis line\necho 'a\\r\\nb' > test.txt\nshould probably be written as\necho -e 'a\\r\\nb' > test.txt\nor better\nprintf 'a\\r\\nb' > test.txt\n\n> I am so confused.\nPlease run\n\nod -c test.txt\nand may be\ngit ls-files --eol\n\n>\n> Any pointers?\n\nhttps://git-scm.com/docs/git-add\n\nWhat happens if you run the following:\nmkdir empty\ncd empty\ngit init\necho \"* -text\" >.gitattributes\nprintf '1\\r\\n2' > test.txt\ngit add .\ngit commit -m \"Add test.txt with CRLF\"\n\necho \"* text=auto eol=lf\" >.gitattributes\ncp test.txt t2.txt\nprintf 'a\\r\\nb' > test.txt\ngit add .\n\ngit commit -m \"cp text.txt t2.txt; change test.txt; eol=input\"\n\ngit add --renormailze test.txt\ngit commit -m \"Normalize line endings in text.txt\"\n\n\n\n"},{"id":"380221","messageId":"0c1b48c9fad641689ead69fdd9f72d63@bofa.com","threadId":"51605","inReplyTo":"20190809033406.5t5ag3qmh36ideec@tb-raspi4","subject":"RE: suggestion for improved docs on autocrlf","fromName":"Yagnatinsky, Mark","fromEmail":"mark.yagnatinsky@bofa.com","sentAt":"2019-08-09T15:34:05Z","receivedAt":"2019-08-09T15:34:10Z","isPatch":false,"sender":{"key":"mark.yagnatinsky@bofa.com","avatar":null},"body":"After correcting spelling of renormalize, the end result of the script you gave is that line endings in working directory are CRLF, and in the repo are LF.\nIs that expected? Surprising? Not sure what you were trying to test there. I also fixed my script to use printf, new version is:\n(using copy/paste this time, instead typing from memory like last time; learned my lesson).\n\nmkdir empty\ncd empty\ngit init\ngit config core.autocrlf false\nprintf '1\\r\\n2' > test.txt\ngit add .\ngit commit -m test\ngit config core.autocrlf input\ncp test.txt t2.txt\nprintf 'a\\r\\nb' > test.txt\ngit add .\n\nThank you for ls-files, I've been resorting to deleting from working directory and then doing a checkout.\nAnd also thank you for the gem of \"od -c\"!\nThe output of ls-files after running my script is:\n\ni/lf w/crlf attr/ t2.txt\ni/crlf w/crlf attr/ test.txt\n\nSo I'm still confused. Why didn't test.txt lose its CRs while t2.txt did?\n\n----------------------------------------------------------------------\nThis message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer. If you are not the intended recipient, please delete this message.\n"},{"id":"380282","messageId":"20190811121004.guygurnopwwggvsp@tb-raspi4","threadId":"51605","inReplyTo":"0c1b48c9fad641689ead69fdd9f72d63@bofa.com","subject":"Re: suggestion for improved docs on autocrlf","fromName":"Torsten Bögershausen","fromEmail":"tboegi@web.de","sentAt":"2019-08-11T12:10:04Z","receivedAt":"2019-08-11T12:10:14Z","isPatch":false,"sender":{"key":"tboegi@web.de","avatar":"https://avatars.githubusercontent.com/u/7138363?v=4"},"body":"On Fri, Aug 09, 2019 at 03:34:05PM +0000, Yagnatinsky, Mark wrote:\n> After correcting spelling of renormalize, the end result of the script you gave is that line endings in working directory are CRLF,\n> and in the repo are LF.\n> Is that expected?\n\nYes. \"git add\" does typically not touch the files on disk at all.\n\n> Surprising?\n\nMay be.\nTypically the CRLF is done in the .gitattributes file,\nwhich is commited and pushed/pulled between the different\nmachines.\nIn opposite, core.autocrlf is just local, and different contributors\nmay use different settings, leading to all kind of CRLF frustrations.\n\nHaving said that, the .gitattributes file is established early in the\nlifetime of a project (=repo).\nI typically set up the .gitattributes file as the first commit,\nbefore adding any other files.\n\nIf, however, the .gitattributes file is added to a repo later\n(better late than never), and the developer messes it up for some\nreasons, then the original files are still in the working tree on\ndisk.\n\nCorrecttions can be made after looking at 'git ls-files --eol' or\nother diagnostics.\n\n>Not sure what you were trying to test there.\nThere ? I probably lost the script.\n\n>I also fixed my script to use printf, new version is:\n> (using copy/paste this time, instead typing from memory like last time; learned my lesson).\n>\n> mkdir empty\n> cd empty\n> git init\n> git config core.autocrlf false\n> printf '1\\r\\n2' > test.txt\n> git add .\n> git commit -m test\n> git config core.autocrlf input\n> cp test.txt t2.txt\n> printf 'a\\r\\nb' > test.txt\n> git add .\n>\n> Thank you for ls-files, I've been resorting to deleting from working directory and then doing a checkout.\n> And also thank you for the gem of \"od -c\"!\n> The output of ls-files after running my script is:\n>\n> i/lf w/crlf attr/ t2.txt\n> i/crlf w/crlf attr/ test.txt\n>\n> So I'm still confused. Why didn't test.txt lose its CRs while t2.txt did?\n\nThis is because the \"auto\" feature does not change the line endings, when a\nfile had been commited with CRLF. They may be there on purpose, or not.\nGit can not make this decision - the user can.\n\nThis is why we have 'git add --renormalize\".\n"},{"id":"380305","messageId":"64c0a35825af4ff3956c6c9a5fb748bb@bofa.com","threadId":"51605","inReplyTo":"20190811121004.guygurnopwwggvsp@tb-raspi4","subject":"RE: suggestion for improved docs on autocrlf","fromName":"Yagnatinsky, Mark","fromEmail":"mark.yagnatinsky@bofa.com","sentAt":"2019-08-12T13:47:18Z","receivedAt":"2019-08-12T13:58:56Z","isPatch":false,"sender":{"key":"mark.yagnatinsky@bofa.com","avatar":null},"body":"Wait a second... suppose a file is committed with CRLF line endings.\nYou're saying that even if I have autocrlf set to \"input\" or \"auto\", the file will never get \"converted\" to LF format unless I explicitly renormalize?\nThat sounds like a fairly sensible behavior, but it's not what I've observed in the past at all!\nThere have been plenty of times when I had \"autocrlf\" set to input which resulted in me changing line endings on commit I had no intention of changing!\nIndeed, the whole reason I was looking at the git docs recently is that this happened again and I was trying to make it stop happening!\nOr is that not what you meant?\n\n----------------------------------------------------------------------\nThis message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer. If you are not the intended recipient, please delete this message.\n"},{"id":"380307","messageId":"xmqqo90ubd3g.fsf@gitster-ct.c.googlers.com","threadId":"51605","inReplyTo":"64c0a35825af4ff3956c6c9a5fb748bb@bofa.com","subject":"Re: suggestion for improved docs on autocrlf","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2019-08-12T15:46:59Z","receivedAt":"2019-08-12T15:47:10Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Yagnatinsky, Mark\" writes:\n\n> Wait a second... suppose a file is committed with CRLF line\n> endings. You're saying that even if I have autocrlf set to\n> \"input\" or \"auto\", the file will never get \"converted\" to LF\n> format unless I explicitly renormalize? That sounds like a fairly\n> sensible behavior, but it's not what I've observed in the past at\n> all! There have been plenty of times when I had \"autocrlf\" set to\n> input which resulted in me changing line endings on commit I had\n> no intention of changing!\n\nIsn't that merely an effect of the fact that git add does not\nbother with paths it knows unmodified, and the decision it makes if\na path is modified does not involve if the path's contents predate\nwhat you have in the current .gitattributes and .git/config?\n\nIf you had committed two paths with CRLF, checked them out, flipped\nthe attribute so that they would be converted upon input, modified\none of them but not the other, and say \"git add .\", because the\nrelative age of .gitattributes and file contents do not get in the\npicture, \"git add .\" would say \"Ah, you have one modified file, so\nwe need to add its new contents to the index. And you are telling\nme to convert its line endings to LF while doing so.\"\n\n"},{"id":"380308","messageId":"c68955b3196a458ca9b502ee8690af8e@bofa.com","threadId":"51605","inReplyTo":"xmqqo90ubd3g.fsf@gitster-ct.c.googlers.com","subject":"RE: suggestion for improved docs on autocrlf","fromName":"Yagnatinsky, Mark","fromEmail":"mark.yagnatinsky@bofa.com","sentAt":"2019-08-12T15:52:40Z","receivedAt":"2019-08-12T15:52:52Z","isPatch":false,"sender":{"key":"mark.yagnatinsky@bofa.com","avatar":null},"body":"But I don't even have a git attributes file! There's no attribute flipping going on, I think.\nThe CRLF'd file was committed by someone else on my team, who probably has git configured differently than I do.\nOr am I missing the point?\n\n----------------------------------------------------------------------\nThis message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer. If you are not the intended recipient, please delete this message.\n"},{"id":"380319","messageId":"20190812171049.ydec3nsmkt2xplhd@tb-raspi4","threadId":"51605","inReplyTo":"64c0a35825af4ff3956c6c9a5fb748bb@bofa.com","subject":"Re: suggestion for improved docs on autocrlf","fromName":"Torsten Bögershausen","fromEmail":"tboegi@web.de","sentAt":"2019-08-12T17:10:49Z","receivedAt":"2019-08-12T17:10:56Z","isPatch":false,"sender":{"key":"tboegi@web.de","avatar":"https://avatars.githubusercontent.com/u/7138363?v=4"},"body":"On Mon, Aug 12, 2019 at 01:47:18PM +0000, Yagnatinsky, Mark wrote:\n> Wait a second... suppose a file is committed with CRLF line endings.\n> You're saying that even if I have autocrlf set to \"input\" or \"auto\", the file will never get \"converted\" to LF format unless I explicitly renormalize?\n\nYes.\n\n> That sounds like a fairly sensible behavior, but it's not what I've observed in the past at all!\n> There have been plenty of times when I had \"autocrlf\" set to input which resulted in me changing line endings on commit I had no intention of changing!\n> Indeed, the whole reason I was looking at the git docs recently is that this happened again and I was trying to make it stop happening!\n> Or is that not what you meant?\n>\nOnly changing core.autocrlf to input will not change the line endings in the repo.\nThat is intentional and allows to to keep core.autocrlf and jump force-and-back in\nthe history by checking out older versions or later versions.\n\nThat is why I would recommend a .gitattributes file,\nwhich travels with the commits and through push and pull.\n\nMy feeling is that the docemntation for core.autocrlf should be:\nThis setting is deprecated. Use a .gitattributes file instead,\nand please see the documentation.\nBut that is clearly debatable.\n\n"},{"id":"380323","messageId":"aae529ce1b084b7bbcca3977e6909417@bofa.com","threadId":"51605","inReplyTo":"20190812171049.ydec3nsmkt2xplhd@tb-raspi4","subject":"RE: suggestion for improved docs on autocrlf","fromName":"Yagnatinsky, Mark","fromEmail":"mark.yagnatinsky@bofa.com","sentAt":"2019-08-12T18:00:08Z","receivedAt":"2019-08-12T18:00:35Z","isPatch":false,"sender":{"key":"mark.yagnatinsky@bofa.com","avatar":null},"body":"Okay, I feel like I'm on the verge of understanding, but it keeps eluding me,\nbecause you keep answering the question I actually asked, rather than the\none I should have asked... let me try again, and bear with me if it seems like I'm\nrepeating the same question over and over, because I don't understand which\n\"irrelevant\" differences matter and which don't.\n(You've been amazingly patient so far actually. Thank you for that.)\n\n(Incidentally, you've successfully convinced me that attributes are a far better\nway to deal with this. I still feel that the behavior should be documented though.)\n\nSetup: Suppose there exists a repo where sample.txt has CRLF line endings.\nMeanwhile, my git config has autocrlf as \"input\". Now, I clone the repo.\nI edit sample.txt, and then commit. Assuming the repo has no .gitattributes,\nis it possible to predict what line endings sample.txt will end up with in my repo?\nOr does it depend on more information than what I've just written?\n\n----------------------------------------------------------------------\nThis message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer. If you are not the intended recipient, please delete this message.\n"},{"id":"380325","messageId":"xmqqo90u9ric.fsf@gitster-ct.c.googlers.com","threadId":"51605","inReplyTo":"aae529ce1b084b7bbcca3977e6909417@bofa.com","subject":"Re: suggestion for improved docs on autocrlf","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2019-08-12T18:18:35Z","receivedAt":"2019-08-12T18:18:43Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Yagnatinsky, Mark\" writes:\n\n> ... Assuming the repo has no .gitattributes,\n> is it possible to predict what line endings sample.txt will end up with in my repo?\n> Or does it depend on more information than what I've just written?\n\nBinary packagers can ship custom attributes and config that applies\nglobally to the installation, which may affect operations in all of\nyour repositories, can't they?\n"},{"id":"380326","messageId":"e47edd8a079d40c8a4151d4d73060b31@bofa.com","threadId":"51605","inReplyTo":"xmqqo90u9ric.fsf@gitster-ct.c.googlers.com","subject":"RE: suggestion for improved docs on autocrlf","fromName":"Yagnatinsky, Mark","fromEmail":"mark.yagnatinsky@bofa.com","sentAt":"2019-08-12T18:30:08Z","receivedAt":"2019-08-12T18:30:15Z","isPatch":false,"sender":{"key":"mark.yagnatinsky@bofa.com","avatar":null},"body":"Okay, let me be more explicit :)\nSuppose \"git check-attr -a .\" produces no output.\nNow, is predictable?\n\n-----Original Message-----\nFrom: git-owner@vger.kernel.org [mailto:git-owner@vger.kernel.org] On Behalf Of Junio C Hamano\nSent: Monday, August 12, 2019 2:19 PM\nTo: Yagnatinsky, Mark \nCc: 'Torsten Bögershausen' ; 'git@vger.kernel.org' \nSubject: Re: suggestion for improved docs on autocrlf\n\n\"Yagnatinsky, Mark\" writes:\n\n> ... Assuming the repo has no .gitattributes,\n> is it possible to predict what line endings sample.txt will end up with in my repo?\n> Or does it depend on more information than what I've just written?\n\nBinary packagers can ship custom attributes and config that applies\nglobally to the installation, which may affect operations in all of\nyour repositories, can't they?\n\n----------------------------------------------------------------------\nThis message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer. If you are not the intended recipient, please delete this message.\n"},{"id":"380357","messageId":"20190813032452.qg2ufgljm4bjeznr@tb-raspi4","threadId":"51605","inReplyTo":"xmqqo90u9ric.fsf@gitster-ct.c.googlers.com","subject":"Re: suggestion for improved docs on autocrlf","fromName":"Torsten Bögershausen","fromEmail":"tboegi@web.de","sentAt":"2019-08-13T03:24:52Z","receivedAt":"2019-08-13T03:25:06Z","isPatch":false,"sender":{"key":"tboegi@web.de","avatar":"https://avatars.githubusercontent.com/u/7138363?v=4"},"body":"On Mon, Aug 12, 2019 at 11:18:35AM -0700, Junio C Hamano wrote:\n> \"Yagnatinsky, Mark\" writes:\n>\n> > ... Assuming the repo has no .gitattributes,\n> > is it possible to predict what line endings sample.txt will end up with in my repo?\n> > Or does it depend on more information than what I've just written?\n>\n\n> Binary packagers can ship custom attributes and config that applies\n> globally to the installation, which may affect operations in all of\n> your repositories, can't they?\n\nLet me try to split my answer into 3 parts:\n- A Git distribution can ship with a global attributes file, but I am not aware of any\n distribution doing this.\n Especially Git for Windpws does not add any (global) .gitattributes file somewhere,\n as far as I know.\n- The default value for the global core.autocrlf is typically unset in all\n Unix-like distributions, which does the same as core.autocrlf=false.\n- The installer for Git for Windows allows the user to choose what the global\n core.autocrlf should be (false, true, input).\n The help text of the installer mentions what\n e.g. \"false\" means (line endings \"as is\"),\n and I don't rember the text for \"true\" and \"input\" out of my head.\n\nNow back to the original question:\n\nPerson A creates a repo with core.autocrlf=false and commite sample.txt with CRLF.\nPerson B clones that repo with CRLF in the repo. When the worktree is checked out,\nsample.txt will have CRLF. Always.\n\nEven if B uses core.autocrlf=input, sample.txt will keep the CRLF when it is commited.\nIf the line endings need to be changed, there are 2 ways:\nEither user B runs dos2unix and commits file with LF.\nOr user B runs `git add --renormalize` sample.txt. That needs a\n`rm sample.txt && git checkout sample.txt` to update the working tree.\n\nAll this is predictable.\nA fresh clone does not have any \"modified files\"; all files with CRLF\nstay with CLRF unless they are normalized.\n\nOur documentation mentions\n\"files that any contributor introduces to the repository\"\n\nIs that part understandalble and the distincion between\n\"existing\" and \"new\" files clear enough ?\n\n\n\n\n"},{"id":"380388","messageId":"a5b84e2b8184414bb416f3aa83361a1c@bofa.com","threadId":"51605","inReplyTo":"20190813032452.qg2ufgljm4bjeznr@tb-raspi4","subject":"RE: suggestion for improved docs on autocrlf","fromName":"Yagnatinsky, Mark","fromEmail":"mark.yagnatinsky@bofa.com","sentAt":"2019-08-13T15:31:43Z","receivedAt":"2019-08-13T15:31:52Z","isPatch":false,"sender":{"key":"mark.yagnatinsky@bofa.com","avatar":null},"body":"Thank you once more. Finally, I believe I understood everything you said.\nI was about to say that this contradicts my own experience.\nBut then I remembered that I normally use my IDE rather than the command line.\nAnd I just checked that indeed that the behavior of my IDE is totally different!\nIt renormalizes line endings of existing files whenever autocrlf is set to input.\nSigh. Okay, great, life makes sense again. I want to yell at my IDE now.\n\nI now feel brave enough to attempt to come up with better wording for autocrlf docs, if you think that's worth trying.\n\n----------------------------------------------------------------------\nThis message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer. If you are not the intended recipient, please delete this message.\n"},{"id":"380389","messageId":"20190813154033.uhi7w5jgwcj4xan7@tb-raspi4","threadId":"51605","inReplyTo":"a5b84e2b8184414bb416f3aa83361a1c@bofa.com","subject":"Re: suggestion for improved docs on autocrlf","fromName":"Torsten Bögershausen","fromEmail":"tboegi@web.de","sentAt":"2019-08-13T15:40:33Z","receivedAt":"2019-08-13T15:40:46Z","isPatch":false,"sender":{"key":"tboegi@web.de","avatar":"https://avatars.githubusercontent.com/u/7138363?v=4"},"body":"On Tue, Aug 13, 2019 at 03:31:43PM +0000, Yagnatinsky, Mark wrote:\n> Thank you once more. Finally, I believe I understood everything you said.\n> I was about to say that this contradicts my own experience.\n> But then I remembered that I normally use my IDE rather than the command line.\n> And I just checked that indeed that the behavior of my IDE is totally different!\n\nWould you like to elobarate which IDE that is?\nThe core.autocrlf handling has been improved a couple of times,\nand it seams that your IDE does things different from git.git\n(Which is not ideal)\n\n> It renormalizes line endings of existing files whenever autocrlf is set to input.\n> Sigh. Okay, great, life makes sense again. I want to yell at my IDE now.\n>\n> I now feel brave enough to attempt to come up with better wording for autocrlf docs, if you think that's worth trying.\n\nThat would be good, I am happy to review patches.\n"},{"id":"380391","messageId":"d4a0500d5f5e4706aef481a33096465a@bofa.com","threadId":"51605","inReplyTo":"20190813154033.uhi7w5jgwcj4xan7@tb-raspi4","subject":"RE: suggestion for improved docs on autocrlf","fromName":"Yagnatinsky, Mark","fromEmail":"mark.yagnatinsky@bofa.com","sentAt":"2019-08-13T15:44:16Z","receivedAt":"2019-08-13T15:44:25Z","isPatch":false,"sender":{"key":"mark.yagnatinsky@bofa.com","avatar":null},"body":"> Would you like to elobarate which IDE that is?\nIntelliJ from JetBrains. I'm planning on emailing them to at least mention this somewhere in their own docs, because I think it's not there.\n\nWill attempt revised wording soon-ish, but not promising today.\n\n----------------------------------------------------------------------\nThis message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer. If you are not the intended recipient, please delete this message.\n"},{"id":"380393","messageId":"xmqq8srx9fy5.fsf@gitster-ct.c.googlers.com","threadId":"51605","inReplyTo":"20190813154033.uhi7w5jgwcj4xan7@tb-raspi4","subject":"Re: suggestion for improved docs on autocrlf","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2019-08-13T16:40:34Z","receivedAt":"2019-08-13T16:40:43Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Torsten Bögershausen writes:\n\n>> Sigh. Okay, great, life makes sense again. I want to yell at my\n>> IDE now.\n>>\n>> I now feel brave enough to attempt to come up with better wording\n>> for autocrlf docs, if you think that's worth trying.\n>\n> That would be good, I am happy to review patches.\n\nGood. Thanks for a good discussion.\n"},{"id":"380445","messageId":"0244daea3faa4d4aa899cff0dcc62917@bofa.com","threadId":"51605","inReplyTo":"d4a0500d5f5e4706aef481a33096465a@bofa.com","subject":"RE: suggestion for improved docs on autocrlf","fromName":"Yagnatinsky, Mark","fromEmail":"mark.yagnatinsky@bofa.com","sentAt":"2019-08-14T16:28:47Z","receivedAt":"2019-08-14T16:28:58Z","isPatch":false,"sender":{"key":"mark.yagnatinsky@bofa.com","avatar":null},"body":"Turns out that this is not intentional behavior of IntelliJ but an unfortunate interaction with a bug in git.\nHad I been using a more recent version of git, it wouldn't be happening.\nhttps://youtrack.jetbrains.com/issue/IDEA-205601\n\nPatched docs on the way eventually. Hopefully it's okay if my syntax is a bit off, I don't know AsciiDoc.\n\n----------------------------------------------------------------------\nThis message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer. If you are not the intended recipient, please delete this message.\n"},{"id":"380468","messageId":"bb706de9a42f4e60ba974647e68f8387@bofa.com","threadId":"51605","inReplyTo":"0244daea3faa4d4aa899cff0dcc62917@bofa.com","subject":"RE: suggestion for improved docs on autocrlf","fromName":"Yagnatinsky, Mark","fromEmail":"mark.yagnatinsky@bofa.com","sentAt":"2019-08-15T04:56:05Z","receivedAt":"2019-08-15T04:56:14Z","isPatch":false,"sender":{"key":"mark.yagnatinsky@bofa.com","avatar":null},"body":"Okay, first attempt at better phrasing. This may need more paragraph breaks, or something.\nRight now it's very wall-of-texty. And probably in a style way too different from the rest of the git docs.\nAlso, the syntax is probably closer to markdown than AsciiDoc; sorry.\nAnyway, enough disclaimers, here's the first draft:\n\nThis variable has three valid settings: true, input, and false.\n(Leaving it unset is equivalent to setting it to \"false\".)\n1. Set it to \"true\" if you want to have CRLF line endings in your \nworking directory and the repository has LF line endings. \nSetting it to true is the same as setting the `text` attribute to\n\"auto\" on all files and core.eol to \"crlf\". In other words: any file\nthat has LF line endings in the repository will have CRLF line\nendings in your working directory. If you commit a new file to\nthe repository, then git will commit it with LF line endings, even\nif it has CRLF endings in your working directory. However, if you\nedit an existing file that has CRLF line endings in the repository,\nthen git will not convert it to LF line endings when you commit it.\n\n2. If you set it to \"input\" then git will not do any line ending conversions\nwhen checking files out of the repository into your working directory.\nThat is, immediately after a checkout, the line endings in your working\ndirectory will match those in the repository. When committing a new\nfile to the repository, git will commit it with LF line endings, even if it has\nCRLF line endings in your working directory. If you edit an existing file in\nthe repository, then:\n * If the file had LF line endings in the repository, it will still have them,\n no matter what line endings are in the working directory.\n * If the file has LF line endings in the working directory, then it will be\n committed with LF line endings , no matter what line endings it used\n to have in the repository.\nIf neither of the above two cases apply, (in other words, if the file has CRLF\nendings in the repository and in also in the working directory), then it will be\ncommitted with CRLF line endings.\n\n3. The simplest setting to explain is \"false\". In this setting, git will not\nperform any line ending conversion; all files will be checked out into\nthe working directory exactly as they are in the repo, and will be\ncommitted to the repo exactly as they are in the working directory.\nThis setting is recommended; if you are tempted to use \"input\" or \"true\"\ninstead of \"false\", then consider looking into committing a .gitattributes file\ninto your repository instead. Settings in that file override this configuration\nvariable, and since the same attributes file is being used by everyone who\nworks on the repo, the results end up being more predictable.\n\nOr something like that.\n\n----------------------------------------------------------------------\nThis message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer. If you are not the intended recipient, please delete this message.\n"},{"id":"380535","messageId":"20190816042025.oiike3cahyfd5h7z@tb-raspi4","threadId":"51605","inReplyTo":"bb706de9a42f4e60ba974647e68f8387@bofa.com","subject":"Re: suggestion for improved docs on autocrlf","fromName":"Torsten Bögershausen","fromEmail":"tboegi@web.de","sentAt":"2019-08-16T04:20:25Z","receivedAt":"2019-08-16T04:20:38Z","isPatch":false,"sender":{"key":"tboegi@web.de","avatar":"https://avatars.githubusercontent.com/u/7138363?v=4"},"body":"On Thu, Aug 15, 2019 at 04:56:05AM +0000, Yagnatinsky, Mark wrote:\n> Okay, first attempt at better phrasing. This may need more paragraph breaks, or something.\n> Right now it's very wall-of-texty. And probably in a style way too different from the rest of the git docs.\n> Also, the syntax is probably closer to markdown than AsciiDoc; sorry.\n> Anyway, enough disclaimers, here's the first draft:\n\nThanks so much for the suggestion.\n\nFeedback and Input like this from Git users are really appreciated.\nI will re-read it a couple of times, and probably find some time\nto make a patch out of it within the next days (or weeks).\n\n>\n> This variable has three valid settings: true, input, and false.\n> (Leaving it unset is equivalent to setting it to \"false\".)\n> 1. Set it to \"true\" if you want to have CRLF line endings in your\n> working directory and the repository has LF line endings.\n> Setting it to true is the same as setting the `text` attribute to\n> \"auto\" on all files and core.eol to \"crlf\". In other words: any file\n> that has LF line endings in the repository will have CRLF line\n> endings in your working directory. If you commit a new file to\n> the repository, then git will commit it with LF line endings, even\n> if it has CRLF endings in your working directory. However, if you\n> edit an existing file that has CRLF line endings in the repository,\n> then git will not convert it to LF line endings when you commit it.\n>\n> 2. If you set it to \"input\" then git will not do any line ending conversions\n> when checking files out of the repository into your working directory.\n> That is, immediately after a checkout, the line endings in your working\n> directory will match those in the repository. When committing a new\n> file to the repository, git will commit it with LF line endings, even if it has\n> CRLF line endings in your working directory. If you edit an existing file in\n> the repository, then:\n> * If the file had LF line endings in the repository, it will still have them,\n> no matter what line endings are in the working directory.\n> * If the file has LF line endings in the working directory, then it will be\n> committed with LF line endings , no matter what line endings it used\n> to have in the repository.\n> If neither of the above two cases apply, (in other words, if the file has CRLF\n> endings in the repository and in also in the working directory), then it will be\n> committed with CRLF line endings.\n>\n> 3. The simplest setting to explain is \"false\". In this setting, git will not\n> perform any line ending conversion; all files will be checked out into\n> the working directory exactly as they are in the repo, and will be\n> committed to the repo exactly as they are in the working directory.\n> This setting is recommended; if you are tempted to use \"input\" or \"true\"\n> instead of \"false\", then consider looking into committing a .gitattributes file\n> into your repository instead. Settings in that file override this configuration\n> variable, and since the same attributes file is being used by everyone who\n> works on the repo, the results end up being more predictable.\n>\n> Or something like that.\n>\n> ----------------------------------------------------------------------\n> This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer. If you are not the intended recipient, please delete this message.\n"},{"id":"380545","messageId":"9dd3ed31c654443b8c6715bb1a15a0c0@bofa.com","threadId":"51605","inReplyTo":"20190816042025.oiike3cahyfd5h7z@tb-raspi4","subject":"RE: suggestion for improved docs on autocrlf","fromName":"Yagnatinsky, Mark","fromEmail":"mark.yagnatinsky@bofa.com","sentAt":"2019-08-16T19:12:41Z","receivedAt":"2019-08-16T19:12:54Z","isPatch":false,"sender":{"key":"mark.yagnatinsky@bofa.com","avatar":null},"body":"Yay! Feel free to tweak and/or butcher the wording, I won't be offended :)\n\n-----Original Message-----\nFrom: Torsten Bögershausen [mailto:tboegi@web.de] \nSent: Friday, August 16, 2019 12:20 AM\nTo: Yagnatinsky, Mark \nCc: 'Junio C Hamano' ; 'git@vger.kernel.org' \nSubject: Re: suggestion for improved docs on autocrlf\n\nOn Thu, Aug 15, 2019 at 04:56:05AM +0000, Yagnatinsky, Mark wrote:\n> Okay, first attempt at better phrasing. This may need more paragraph breaks, or something.\n> Right now it's very wall-of-texty. And probably in a style way too different from the rest of the git docs.\n> Also, the syntax is probably closer to markdown than AsciiDoc; sorry.\n> Anyway, enough disclaimers, here's the first draft:\n\nThanks so much for the suggestion.\n\nFeedback and Input like this from Git users are really appreciated.\nI will re-read it a couple of times, and probably find some time\nto make a patch out of it within the next days (or weeks).\n\n>\n> This variable has three valid settings: true, input, and false.\n> (Leaving it unset is equivalent to setting it to \"false\".)\n> 1. Set it to \"true\" if you want to have CRLF line endings in your\n> working directory and the repository has LF line endings.\n> Setting it to true is the same as setting the `text` attribute to\n> \"auto\" on all files and core.eol to \"crlf\". In other words: any file\n> that has LF line endings in the repository will have CRLF line\n> endings in your working directory. If you commit a new file to\n> the repository, then git will commit it with LF line endings, even\n> if it has CRLF endings in your working directory. However, if you\n> edit an existing file that has CRLF line endings in the repository,\n> then git will not convert it to LF line endings when you commit it.\n>\n> 2. If you set it to \"input\" then git will not do any line ending conversions\n> when checking files out of the repository into your working directory.\n> That is, immediately after a checkout, the line endings in your working\n> directory will match those in the repository. When committing a new\n> file to the repository, git will commit it with LF line endings, even if it has\n> CRLF line endings in your working directory. If you edit an existing file in\n> the repository, then:\n> * If the file had LF line endings in the repository, it will still have them,\n> no matter what line endings are in the working directory.\n> * If the file has LF line endings in the working directory, then it will be\n> committed with LF line endings , no matter what line endings it used\n> to have in the repository.\n> If neither of the above two cases apply, (in other words, if the file has CRLF\n> endings in the repository and in also in the working directory), then it will be\n> committed with CRLF line endings.\n>\n> 3. The simplest setting to explain is \"false\". In this setting, git will not\n> perform any line ending conversion; all files will be checked out into\n> the working directory exactly as they are in the repo, and will be\n> committed to the repo exactly as they are in the working directory.\n> This setting is recommended; if you are tempted to use \"input\" or \"true\"\n> instead of \"false\", then consider looking into committing a .gitattributes file\n> into your repository instead. Settings in that file override this configuration\n> variable, and since the same attributes file is being used by everyone who\n> works on the repo, the results end up being more predictable.\n>\n> Or something like that.\n>\n> ----------------------------------------------------------------------\n> This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer. If you are not the intended recipient, please delete this message.\n\n----------------------------------------------------------------------\nThis message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer. If you are not the intended recipient, please delete this message.\n"}]}