{"thread":{"id":"39685","subject":"'eol' documentation confusion","startedAt":"2015-06-21T14:04:51Z","lastAt":"2015-06-25T15:31:27Z","messageCount":5,"participants":["Robert Dailey","Torsten Bögershausen","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"264439","messageId":"CAHd499CapqvC3pHszgmX2VexdmqiW4+N23YfkAP5jjXWDrbe0A@mail.gmail.com","threadId":"39685","inReplyTo":null,"subject":"'eol' documentation confusion","fromName":"Robert Dailey","fromEmail":"rcdailey.lists@gmail.com","sentAt":"2015-06-21T14:04:51Z","receivedAt":"2015-06-21T14:04:51Z","isPatch":false,"sender":{"key":"rcdailey.lists@gmail.com","avatar":null},"body":"Upon inspection of the gitattributes documentation page here:\nhttps://git-scm.com/docs/gitattributes\n\nWhen comparing the documentation for 'text' with 'eol', I see the\nfollowing missing explanations for 'eol':\n\n* eol\n* -eol\n\nMaybe the fact that these are missing means they are not valid to use.\nThere is also the issue that `text` usually controls EOL anyway. Is\nthere ever any reason to set eol in a way differently than explained\nin the documentation (that is, `eol=lf` or `eol=crlf`)?\n\nFor example, what if you want a file to be treated as text BUT you do\nnot want it to perform EOL normalization at all. Could you do this?\n\n foo.txt text -eol\n\nJust at first glance, this to me would mean line endings on checkin\nand checkout are not touched (CRLF could be checked in). Is this\npossible?\n\nWhat about setting `eol` but not `text`?\n\nHonestly it seems like `eol` is just a supplementary setting for\n`text` and was never intended to be used in ways that are\nundocumented. Some explanation to help uncloud this would help, or\nmaybe I missed something in the documentation that explains this.\n"},{"id":"264441","messageId":"CAHd499Do_bpdOkL2TqdO+8L=pR53117pKR0GSwdgvFDwq_S4=w@mail.gmail.com","threadId":"39685","inReplyTo":"CAHd499CapqvC3pHszgmX2VexdmqiW4+N23YfkAP5jjXWDrbe0A@mail.gmail.com","subject":"Re: 'eol' documentation confusion","fromName":"Robert Dailey","fromEmail":"rcdailey.lists@gmail.com","sentAt":"2015-06-21T14:16:03Z","receivedAt":"2015-06-21T14:16:03Z","isPatch":false,"sender":{"key":"rcdailey.lists@gmail.com","avatar":null},"body":"On Sun, Jun 21, 2015 at 9:04 AM, Robert Dailey wrote:\n> Upon inspection of the gitattributes documentation page here:\n> https://git-scm.com/docs/gitattributes\n>\n> When comparing the documentation for 'text' with 'eol', I see the\n> following missing explanations for 'eol':\n>\n> * eol\n> * -eol\n>\n> Maybe the fact that these are missing means they are not valid to use.\n> There is also the issue that `text` usually controls EOL anyway. Is\n> there ever any reason to set eol in a way differently than explained\n> in the documentation (that is, `eol=lf` or `eol=crlf`)?\n>\n> For example, what if you want a file to be treated as text BUT you do\n> not want it to perform EOL normalization at all. Could you do this?\n>\n> foo.txt text -eol\n>\n> Just at first glance, this to me would mean line endings on checkin\n> and checkout are not touched (CRLF could be checked in). Is this\n> possible?\n>\n> What about setting `eol` but not `text`?\n>\n> Honestly it seems like `eol` is just a supplementary setting for\n> `text` and was never intended to be used in ways that are\n> undocumented. Some explanation to help uncloud this would help, or\n> maybe I missed something in the documentation that explains this.\n\nI did a few tests out of curiosity:\n\n * eol\n\nThis allowed CRLF to be committed in a file named `foo.txt` (I saw ^M\nin the diff, which I think means CR character, and treats this\ncharacter as an error)\n\n * text=auto eol\n\nThis did not differ in behavior from `* text=auto` from what I could\nsee. It removed CR characters in the repository on check in.\n\n * text=auto -eol\n\nSame as before, the addition of `-eol` did not change the behavior at all.\n\nSo yeah, I'm still horribly confused. None of these scenarios make any\nsense. The only time I ever set `eol` explicitly is to either do\n`eol=lf` or `eol=crlf`.\n"},{"id":"264489","messageId":"5587AAB2.80305@web.de","threadId":"39685","inReplyTo":"CAHd499Do_bpdOkL2TqdO+8L=pR53117pKR0GSwdgvFDwq_S4=w@mail.gmail.com","subject":"Re: 'eol' documentation confusion","fromName":"Torsten Bögershausen","fromEmail":"tboegi@web.de","sentAt":"2015-06-22T06:26:58Z","receivedAt":"2015-06-22T06:26:58Z","isPatch":false,"sender":{"key":"tboegi@web.de","avatar":"https://avatars.githubusercontent.com/u/7138363?v=4"},"body":"On 06/21/2015 04:16 PM, Robert Dailey wrote:\n> On Sun, Jun 21, 2015 at 9:04 AM, Robert Dailey wrote:\n>> Upon inspection of the gitattributes documentation page here:\n>> https://git-scm.com/docs/gitattributes\n>>\n>> When comparing the documentation for 'text' with 'eol', I see the\n>> following missing explanations for 'eol':\n>>\n>> * eol\n>> * -eol\n>>\n>> Maybe the fact that these are missing means they are not valid to use.\n>> There is also the issue that `text` usually controls EOL anyway. Is\n>> there ever any reason to set eol in a way differently than explained\n>> in the documentation (that is, `eol=lf` or `eol=crlf`)?\nNo.\neol=lf or eol=crlf are the only useful settings.\nEverything else is ignored because it does not make sense.\n\nSee convert.c:\nstatic enum eol git_path_check_eol()\n"},{"id":"264566","messageId":"xmqqr3p3iuyc.fsf@gitster.dls.corp.google.com","threadId":"39685","inReplyTo":"5587AAB2.80305@web.de","subject":"Re: 'eol' documentation confusion","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-06-22T16:11:55Z","receivedAt":"2015-06-22T16:11:55Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Torsten Bögershausen writes:\n\n> eol=lf or eol=crlf are the only useful settings.\n> Everything else is ignored because it does not make sense.\n>\n> See convert.c:\n> static enum eol git_path_check_eol()\n\nThat makes me wonder...\n\nThe original reasoning behind the current behaviour that we ignore\nunknown values given to configuration variables and attributes is so\nthat people can use the same file that has values that are\nunderstood by newer versions of Git with older versions of Git.\n\nYou may be trying the eol=cleverLF setting introduced in Git version\n47-prerelease by adding it to .git/info/attributes, and may have\nfound it useful. But you may also have to use the same repository\non another machine that you didn't install that future version of\nGit over the network filesystem. Barfing and not proceeding when we\nsee unknown eol=cleverLF does not sound like a nice thing to do,\nwhich is why we just ignore and behave as if the setting was not\nthere.\n\nIdeally, however, I think we should ignore an unknown setting as\nlong as it does not matter (i.e. we do not come to the codepath that\nwants to know eol settings for the path, e.g. running \"git log\" to\nshow only the commit log messages and the topology of the history),\nbut we should error out when the unknown setting possibly matters\n(i.e. we do need the eol setting for the path in order to correctly\nconvert the contents to end-user's liking).\n\nThoughts (and patches ;-)?\n"},{"id":"264860","messageId":"558C1ECF.1030801@web.de","threadId":"39685","inReplyTo":"xmqqr3p3iuyc.fsf@gitster.dls.corp.google.com","subject":"Re: 'eol' documentation confusion","fromName":"Torsten Bögershausen","fromEmail":"tboegi@web.de","sentAt":"2015-06-25T15:31:27Z","receivedAt":"2015-06-25T15:31:27Z","isPatch":false,"sender":{"key":"tboegi@web.de","avatar":"https://avatars.githubusercontent.com/u/7138363?v=4"},"body":"On 2015-06-22 18.11, Junio C Hamano wrote:\n> Torsten Bögershausen writes:\n> \n>> eol=lf or eol=crlf are the only useful settings.\n>> Everything else is ignored because it does not make sense.\n>>\n>> See convert.c:\n>> static enum eol git_path_check_eol()\n> \n> That makes me wonder...\n> \n> The original reasoning behind the current behaviour that we ignore\n> unknown values given to configuration variables and attributes is so\n> that people can use the same file that has values that are\n> understood by newer versions of Git with older versions of Git.\n> \n> You may be trying the eol=cleverLF setting introduced in Git version\n> 47-prerelease by adding it to .git/info/attributes, and may have\n> found it useful. But you may also have to use the same repository\n> on another machine that you didn't install that future version of\n> Git over the network filesystem. Barfing and not proceeding when we\n> see unknown eol=cleverLF does not sound like a nice thing to do,\n> which is why we just ignore and behave as if the setting was not\n> there.\n> \n> Ideally, however, I think we should ignore an unknown setting as\n> long as it does not matter (i.e. we do not come to the codepath that\n> wants to know eol settings for the path, e.g. running \"git log\" to\n> show only the commit log messages and the topology of the history),\n> but we should error out when the unknown setting possibly matters\n> (i.e. we do need the eol setting for the path in order to correctly\n> convert the contents to end-user's liking).\n> \n> Thoughts (and patches ;-)?\nIn short:\nGood idea, patches follow within the next weeks/months\n"}]}