{"thread":{"id":"57221","subject":"[PATCH 0/2] Improvements to tests and docs for .gitattributes eol","startedAt":"2022-01-11T02:19:07Z","lastAt":"2023-02-06T21:56:53Z","messageCount":24,"participants":["brian m. carlson","Torsten B��gershausen","Derrick Stolee","Junio C Hamano","Johannes Sixt","Philip Oakley","Ævar Arnfjörð Bjarmason","Torsten Bögershausen"],"isPatch":true,"patchVersion":1,"patchTotal":2},"messages":[{"id":"445891","messageId":"20220111021507.531736-1-sandals@crustytoothpaste.net","threadId":"57221","inReplyTo":null,"subject":"[PATCH 0/2] Improvements to tests and docs for .gitattributes eol","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2022-01-11T02:15:05Z","receivedAt":"2022-01-11T02:19:07Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"I was answering a question on StackOverflow recently about the\ninteraction between text=auto and eol, and someone pointed out to me\nthat what I had written, which was based on the documentation, was not\ncorrect as of Git 2.10 (and more specifically 6523728499 (\"convert:\nunify the \"auto\" handling of CRLF\", 2016-06-28)).\n\nWhen I set out to document the behavior correctly, I ran into the fact\nthat the tests, where I looked for examples of how this behaves, didn't\nhave any tests for some of these cases, and so I had some trouble\ndocumenting this clearly and accurately.  So this series basically just\nadds some tests for existing behavior so we don't change it (and so I\ncould figure out how it works) and then updates the documentation\naccordingly.\n\nI tried to make the docs as specific as possible, since I needed them to\nbe specific and accurate here, and I felt like speaking affirmatively\nabout the behavior would be clearer than speaking negatively about the\nbehavior (I tried both).  I would of course be delighted to hear\nsuggestions on how this could be clearer or easier to understand.\n\nI realize that 2.35.0-rc0 has just come out and so this won't be picked\nup right away, which is fine, but I thought I'd send it out\nnevertheless (mostly so I don't forget).\n\nbrian m. carlson (2):\n  t0027: add tests for eol without text in .gitattributes\n  docs: correct documentation about eol attribute\n\n Documentation/gitattributes.txt | 11 ++++++-----\n t/t0027-auto-crlf.sh            |  6 ++++++\n 2 files changed, 12 insertions(+), 5 deletions(-)\n\n"},{"id":"445892","messageId":"20220111021507.531736-2-sandals@crustytoothpaste.net","threadId":"57221","inReplyTo":"20220111021507.531736-1-sandals@crustytoothpaste.net","subject":"[PATCH 1/2] t0027: add tests for eol without text in .gitattributes","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2022-01-11T02:15:06Z","receivedAt":"2022-01-11T02:19:08Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"Right now, it isn't clear what the behavior is when the eol attribute is\nset in .gitattributes but the text attribute is not.  Let's add some\ntests to document this behavior in our code, which happens to be that\nthe behavior is as if we set the text attribute implicitly.  This will\nmake sure we don't accidentally change the behavior, which somebody is\nprobably relying on, and serve as documentation to developers.\n\nSigned-off-by: brian m. carlson <sandals@crustytoothpaste.net>\n---\n t/t0027-auto-crlf.sh | 6 ++++++\n 1 file changed, 6 insertions(+)\n\ndiff --git a/t/t0027-auto-crlf.sh b/t/t0027-auto-crlf.sh\nindex 4a5c5c602c..c5f7ac63b0 100755\n--- a/t/t0027-auto-crlf.sh\n+++ b/t/t0027-auto-crlf.sh\n@@ -597,6 +597,12 @@ do\n \t# auto: core.autocrlf=false and core.eol unset(or native) uses native eol\n \tcheckout_files     auto  \"$id\" \"\"     false   \"\"       $NL   CRLF  CRLF_mix_LF  LF_mix_CR    LF_nul\n \tcheckout_files     auto  \"$id\" \"\"     false   native   $NL   CRLF  CRLF_mix_LF  LF_mix_CR    LF_nul\n+\t# core.autocrlf false, .gitattributes sets eol\n+\tcheckout_files     \"\"    \"$id\" \"lf\"   false   \"\"       LF    CRLF  CRLF_mix_LF  LF_mix_CR    LF_nul\n+\tcheckout_files     \"\"    \"$id\" \"crlf\" false   \"\"       CRLF  CRLF  CRLF         CRLF_mix_CR  CRLF_nul\n+\t# core.autocrlf true, .gitattributes sets eol\n+\tcheckout_files     \"\"    \"$id\" \"lf\"   true    \"\"       LF    CRLF  CRLF_mix_LF  LF_mix_CR    LF_nul\n+\tcheckout_files     \"\"    \"$id\" \"crlf\" true    \"\"       CRLF  CRLF  CRLF         CRLF_mix_CR  CRLF_nul\n done\n \n # The rest of the tests are unique; do the usual linting.\n"},{"id":"445893","messageId":"20220111021507.531736-3-sandals@crustytoothpaste.net","threadId":"57221","inReplyTo":"20220111021507.531736-1-sandals@crustytoothpaste.net","subject":"[PATCH 2/2] docs: correct documentation about eol attribute","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2022-01-11T02:15:07Z","receivedAt":"2022-01-11T02:19:08Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"The documentation for the eol attribute states that it is \"effectively\nsetting the text attribute\".  However, this implies that it forces the\ntext attribute to always be set, which has not been the case since\n6523728499 (\"convert: unify the \"auto\" handling of CRLF\", 2016-06-28).\nLet's avoid confusing users (and the present author when trying to\ndescribe Git's behavior to others) by clearly documenting in which\ncases the \"eol\" attribute has effect.\n\nSpecifically, the attribute always has an effect unless the file is\nexplicitly set as -text, or the file is set as text=auto and the file is\ndetected as binary.\n\nSigned-off-by: brian m. carlson <sandals@crustytoothpaste.net>\n---\n Documentation/gitattributes.txt | 11 ++++++-----\n 1 file changed, 6 insertions(+), 5 deletions(-)\n\ndiff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt\nindex 83fd4e19a4..60984a4682 100644\n--- a/Documentation/gitattributes.txt\n+++ b/Documentation/gitattributes.txt\n@@ -160,11 +160,12 @@ unspecified.\n ^^^^^\n \n This attribute sets a specific line-ending style to be used in the\n-working directory.  It enables end-of-line conversion without any\n-content checks, effectively setting the `text` attribute.  Note that\n-setting this attribute on paths which are in the index with CRLF line\n-endings may make the paths to be considered dirty.  Adding the path to\n-the index again will normalize the line endings in the index.\n+working directory.  This attribute has effect only if the `text`\n+attribute is set or unspecified, or if it is set to `auto` and the file\n+is detected as text.  Note that setting this attribute on paths which\n+are in the index with CRLF line endings may make the paths to be\n+considered dirty. Adding the path to the index again will normalize the\n+line endings in the index.\n \n Set to string value \"crlf\"::\n \n"},{"id":"445949","messageId":"20220111183003.g4fch5d2f47it2hg@tb-raspi4","threadId":"57221","inReplyTo":"20220111021507.531736-3-sandals@crustytoothpaste.net","subject":"Re: [PATCH 2/2] docs: correct documentation about eol attribute","fromName":"Torsten B��gershausen","fromEmail":"tboegi@web.de","sentAt":"2022-01-11T18:30:03Z","receivedAt":"2022-01-11T18:35:36Z","isPatch":true,"sender":{"key":"tboegi@web.de","avatar":"https://avatars.githubusercontent.com/u/7138363?v=4"},"body":"Hej Brian,\nthanks for digging into this.\n\nCould you be so kind to send the stackoverflow issue ?\n(You can send it to me only)\n\nI have some comments/questions, out of my head.\n\nOn Tue, Jan 11, 2022 at 02:15:07AM +0000, brian m. carlson wrote:\n> The documentation for the eol attribute states that it is \"effectively\n> setting the text attribute\".\n> Let's avoid confusing users (and the present author when trying to\n> describe Git's behavior to others) by clearly documenting in which\n> cases the \"eol\" attribute has effect.\n>\n> Specifically, the attribute always has an effect unless the file is\n> explicitly set as -text, or the file is set as text=auto and the file is\n> detected as binary.\n>\n> Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>\n> ---\n>  Documentation/gitattributes.txt | 11 ++++++-----\n>  1 file changed, 6 insertions(+), 5 deletions(-)\n>\n> diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt\n> index 83fd4e19a4..60984a4682 100644\n> --- a/Documentation/gitattributes.txt\n> +++ b/Documentation/gitattributes.txt\n> @@ -160,11 +160,12 @@ unspecified.\n>  ^^^^^\n>\n>  This attribute sets a specific line-ending style to be used in the\n> -working directory.  It enables end-of-line conversion without any\n> -content checks, effectively setting the `text` attribute.  Note that\n> -setting this attribute on paths which are in the index with CRLF line\n> -endings may make the paths to be considered dirty.  Adding the path to\n> -the index again will normalize the line endings in the index.\n> +working directory.  This attribute has effect only if the `text`\n> +attribute is set or unspecified, or if it is set to `auto` and the file\n> +is detected as text.\n\n\n\n>  Note that setting this attribute on paths which\n> +are in the index with CRLF line endings may make the paths to be\n> +considered dirty. Adding the path to the index again will normalize the\n> +line endings in the index.\n\nI think that this can be loosened as well. And, beside this, the \"dirty\"\nwarning about setting attributes could be written as part of the \"text\"\nattribute as well. I dunno. Here is a possible suggestion:\n\n\n  Note that setting this attribute on paths which are in the index with CRLF\n  line endings may make the paths to be considered dirty - unless \"text=auto\"\n  is set. `git ls-files --eol` can be used to check the \"line ending status\".\n  Adding the path to the index again will normalize the line endings in the index.\n\n>\n>  Set to string value \"crlf\"::\n>\n"},{"id":"445978","messageId":"Yd4Hb/bxvJZkJP7P@camp.crustytoothpaste.net","threadId":"57221","inReplyTo":"20220111183003.g4fch5d2f47it2hg@tb-raspi4","subject":"Re: [PATCH 2/2] docs: correct documentation about eol attribute","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2022-01-11T22:40:47Z","receivedAt":"2022-01-11T22:40:53Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2022-01-11 at 18:30:03, Torsten Bögershausen wrote:\n> Hej Brian,\n> thanks for digging into this.\n> \n> Could you be so kind to send the stackoverflow issue ?\n> (You can send it to me only)\n\nI'll just post it here publicly, since I think there's value to folks\nseeing what questions users have:\n\nhttps://stackoverflow.com/questions/70633469/what-is-the-difference-between-text-auto-and-text-auto-eol-lf/70636508?\n\n> On Tue, Jan 11, 2022 at 02:15:07AM +0000, brian m. carlson wrote:\n> >  Note that setting this attribute on paths which\n> > +are in the index with CRLF line endings may make the paths to be\n> > +considered dirty. Adding the path to the index again will normalize the\n> > +line endings in the index.\n> \n> I think that this can be loosened as well. And, beside this, the \"dirty\"\n> warning about setting attributes could be written as part of the \"text\"\n> attribute as well. I dunno. Here is a possible suggestion:\n> \n> \n>   Note that setting this attribute on paths which are in the index with CRLF\n>   line endings may make the paths to be considered dirty - unless \"text=auto\"\n>   is set. `git ls-files --eol` can be used to check the \"line ending status\".\n>   Adding the path to the index again will normalize the line endings in the index.\n\nI'm not sure that's correct, though.  The problem is if the file is\ndetected as text, which it might well be if text=auto is set.  Or am I\nnot understanding something correctly?\n-- \nbrian m. carlson (he/him or they/them)\nToronto, Ontario, CA\n"},{"id":"446028","messageId":"20220112151657.4yy7q6pk54v4w2eh@tb-raspi4","threadId":"57221","inReplyTo":"Yd4Hb/bxvJZkJP7P@camp.crustytoothpaste.net","subject":"Re: [PATCH 2/2] docs: correct documentation about eol attribute","fromName":"Torsten B��gershausen","fromEmail":"tboegi@web.de","sentAt":"2022-01-12T15:16:57Z","receivedAt":"2022-01-12T15:17:28Z","isPatch":true,"sender":{"key":"tboegi@web.de","avatar":"https://avatars.githubusercontent.com/u/7138363?v=4"},"body":"On Tue, Jan 11, 2022 at 10:40:47PM +0000, brian m. carlson wrote:\n> On 2022-01-11 at 18:30:03, Torsten B??gershausen wrote:\n> > Hej Brian,\n> > thanks for digging into this.\n> >\n> > Could you be so kind to send the stackoverflow issue ?\n> > (You can send it to me only)\n>\n> I'll just post it here publicly, since I think there's value to folks\n> seeing what questions users have:\n\nThanks - Please see the comments inline, as usual.\n\n>\n> https://stackoverflow.com/questions/70633469/what-is-the-difference-between-text-auto-and-text-auto-eol-lf/70636508?\n\nTo pick up the question here:\n\n  I was reading about the .gitattributes file and the rule to force line endings\n  in some tutorials it's written like\n  * text=auto\n  and in some others, it's like\n  * text=auto eol=lf\n  at the first line of the file.\n\n  Are there any differences? what does the first one exactly do? Does it even force any line endings?\n[]\n\nYes, there are differences.\nThe line\n* text=auto\nwill make sure that all by-Git-as-text-files-detected files\nwill be commited with LF into the repo.\nCRLF in the working tree will become LF in the repo.\n\nWhen the files are checkout, the line endings depend on local\ngit config settings:\ncore.autocrlf=true will give CRLF\ncore.autocrlf=input will give LF\nWhen core.autocrlf is false (or unset) git looks at core.eol:\ncore.eol=crlf gives CRLF\ncore.eol=lf gives LF\ncore.eol unset (or native) will use the the native line endings,\nCRLF on Windows, LF everywhere else.\n--------------\nLet's look at\n* text=auto eol=lf\n\nHere Git does not look at any local config variables.\nAll files will be checkout out with LF, even on Windows.\n\n>\n> > On Tue, Jan 11, 2022 at 02:15:07AM +0000, brian m. carlson wrote:\n> > >  Note that setting this attribute on paths which\n> > > +are in the index with CRLF line endings may make the paths to be\n> > > +considered dirty. Adding the path to the index again will normalize the\n> > > +line endings in the index.\n> >\n> > I think that this can be loosened as well. And, beside this, the \"dirty\"\n> > warning about setting attributes could be written as part of the \"text\"\n> > attribute as well. I dunno. Here is a possible suggestion:\n> >\n> >\n> >   Note that setting this attribute on paths which are in the index with CRLF\n> >   line endings may make the paths to be considered dirty - unless \"text=auto\"\n> >   is set. `git ls-files --eol` can be used to check the \"line ending status\".\n> >   Adding the path to the index again will normalize the line endings in the index.\n>\n> I'm not sure that's correct, though.  The problem is if the file is\n> detected as text, which it might well be if text=auto is set.  Or am I\n> not understanding something correctly?\n\nWhich problem are we talking about ?\nFiles that once had been commited with CRLF into the repo are\nnow considered dirty?\nThe \"new safer autocrlf-handling\" will not try to normalize them\nwhen text=auto is specified.\nThey keep their existing line endings at checkout or checkin.\n\nI hope this makes sense ?\n\n"},{"id":"448343","messageId":"20220214020827.1508706-1-sandals@crustytoothpaste.net","threadId":"57221","inReplyTo":"20220111021507.531736-1-sandals@crustytoothpaste.net","subject":"[PATCH v2 0/2] Improvements to tests and docs for .gitattributes eol","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2022-02-14T02:08:25Z","receivedAt":"2022-02-14T02:08:46Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"I was answering a question on StackOverflow recently about the\ninteraction between text=auto and eol, and someone pointed out to me\nthat what I had written, which was based on the documentation, was not\ncorrect as of Git 2.10 (and more specifically 6523728499 (\"convert:\nunify the \"auto\" handling of CRLF\", 2016-06-28)).\n\nWhen I set out to document the behavior correctly, I ran into the fact\nthat the tests, where I looked for examples of how this behaves, didn't\nhave any tests for some of these cases, and so I had some trouble\ndocumenting this clearly and accurately.  So this series basically just\nadds some tests for existing behavior so we don't change it (and so I\ncould figure out how it works) and then updates the documentation\naccordingly.\n\nChanges from v1:\n* Correct documentation inaccuracy with respect to text=auto.\n\nbrian m. carlson (2):\n  t0027: add tests for eol without text in .gitattributes\n  docs: correct documentation about eol attribute\n\n Documentation/gitattributes.txt | 12 +++++++-----\n t/t0027-auto-crlf.sh            |  6 ++++++\n 2 files changed, 13 insertions(+), 5 deletions(-)\n\n"},{"id":"448344","messageId":"20220214020827.1508706-3-sandals@crustytoothpaste.net","threadId":"57221","inReplyTo":"20220214020827.1508706-1-sandals@crustytoothpaste.net","subject":"[PATCH v2 2/2] docs: correct documentation about eol attribute","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2022-02-14T02:08:27Z","receivedAt":"2022-02-14T02:08:47Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"The documentation for the eol attribute states that it is \"effectively\nsetting the text attribute\".  However, this implies that it forces the\ntext attribute to always be set, which has not been the case since\n6523728499 (\"convert: unify the \"auto\" handling of CRLF\", 2016-06-28).\nLet's avoid confusing users (and the present author when trying to\ndescribe Git's behavior to others) by clearly documenting in which\ncases the \"eol\" attribute has effect.\n\nSpecifically, the attribute always has an effect unless the file is\nexplicitly set as -text, or the file is set as text=auto and the file is\ndetected as binary or has CRLF endings.  It used to be the case that\ntext=auto did cause automatic conversion of files with CRLF endings, but\nthat is no longer the case, so let's document that fact as well.\n\nSigned-off-by: brian m. carlson <sandals@crustytoothpaste.net>\n---\n Documentation/gitattributes.txt | 12 +++++++-----\n 1 file changed, 7 insertions(+), 5 deletions(-)\n\ndiff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt\nindex 83fd4e19a4..a71dad2674 100644\n--- a/Documentation/gitattributes.txt\n+++ b/Documentation/gitattributes.txt\n@@ -160,11 +160,13 @@ unspecified.\n ^^^^^\n \n This attribute sets a specific line-ending style to be used in the\n-working directory.  It enables end-of-line conversion without any\n-content checks, effectively setting the `text` attribute.  Note that\n-setting this attribute on paths which are in the index with CRLF line\n-endings may make the paths to be considered dirty.  Adding the path to\n-the index again will normalize the line endings in the index.\n+working directory.  This attribute has effect only if the `text`\n+attribute is set or unspecified, or if it is set to `auto`, the file is\n+detected as text, and it is stored with LF endings in the index.  Note\n+that setting this attribute on paths which are in the index with CRLF\n+line endings may make the paths to be considered dirty unless\n+`text=auto` is set. Adding the path to the index again will normalize\n+the line endings in the index.\n \n Set to string value \"crlf\"::\n \n"},{"id":"448345","messageId":"20220214020827.1508706-2-sandals@crustytoothpaste.net","threadId":"57221","inReplyTo":"20220214020827.1508706-1-sandals@crustytoothpaste.net","subject":"[PATCH v2 1/2] t0027: add tests for eol without text in .gitattributes","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2022-02-14T02:08:26Z","receivedAt":"2022-02-14T02:08:48Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"Right now, it isn't clear what the behavior is when the eol attribute is\nset in .gitattributes but the text attribute is not.  Let's add some\ntests to document this behavior in our code, which happens to be that\nthe behavior is as if we set the text attribute implicitly.  This will\nmake sure we don't accidentally change the behavior, which somebody is\nprobably relying on, and serve as documentation to developers.\n\nSigned-off-by: brian m. carlson <sandals@crustytoothpaste.net>\n---\n t/t0027-auto-crlf.sh | 6 ++++++\n 1 file changed, 6 insertions(+)\n\ndiff --git a/t/t0027-auto-crlf.sh b/t/t0027-auto-crlf.sh\nindex 4a5c5c602c..c5f7ac63b0 100755\n--- a/t/t0027-auto-crlf.sh\n+++ b/t/t0027-auto-crlf.sh\n@@ -597,6 +597,12 @@ do\n \t# auto: core.autocrlf=false and core.eol unset(or native) uses native eol\n \tcheckout_files     auto  \"$id\" \"\"     false   \"\"       $NL   CRLF  CRLF_mix_LF  LF_mix_CR    LF_nul\n \tcheckout_files     auto  \"$id\" \"\"     false   native   $NL   CRLF  CRLF_mix_LF  LF_mix_CR    LF_nul\n+\t# core.autocrlf false, .gitattributes sets eol\n+\tcheckout_files     \"\"    \"$id\" \"lf\"   false   \"\"       LF    CRLF  CRLF_mix_LF  LF_mix_CR    LF_nul\n+\tcheckout_files     \"\"    \"$id\" \"crlf\" false   \"\"       CRLF  CRLF  CRLF         CRLF_mix_CR  CRLF_nul\n+\t# core.autocrlf true, .gitattributes sets eol\n+\tcheckout_files     \"\"    \"$id\" \"lf\"   true    \"\"       LF    CRLF  CRLF_mix_LF  LF_mix_CR    LF_nul\n+\tcheckout_files     \"\"    \"$id\" \"crlf\" true    \"\"       CRLF  CRLF  CRLF         CRLF_mix_CR  CRLF_nul\n done\n \n # The rest of the tests are unique; do the usual linting.\n"},{"id":"448357","messageId":"d4d4a72c-3bf2-410e-773f-118a1834a386@github.com","threadId":"57221","inReplyTo":"20220214020827.1508706-1-sandals@crustytoothpaste.net","subject":"Re: [PATCH v2 0/2] Improvements to tests and docs for .gitattributes eol","fromName":"Derrick Stolee","fromEmail":"derrickstolee@github.com","sentAt":"2022-02-14T14:52:58Z","receivedAt":"2022-02-14T14:53:07Z","isPatch":true,"sender":{"key":"stolee@gmail.com","avatar":"https://avatars.githubusercontent.com/u/570044?v=4"},"body":"On 2/13/2022 9:08 PM, brian m. carlson wrote:\n> I was answering a question on StackOverflow recently about the\n> interaction between text=auto and eol, and someone pointed out to me\n> that what I had written, which was based on the documentation, was not\n> correct as of Git 2.10 (and more specifically 6523728499 (\"convert:\n> unify the \"auto\" handling of CRLF\", 2016-06-28)).\n> \n> When I set out to document the behavior correctly, I ran into the fact\n> that the tests, where I looked for examples of how this behaves, didn't\n> have any tests for some of these cases, and so I had some trouble\n> documenting this clearly and accurately.  So this series basically just\n> adds some tests for existing behavior so we don't change it (and so I\n> could figure out how it works) and then updates the documentation\n> accordingly.\n\nThanks for these updates. They look good as-is.\n\n-Stolee\n\n"},{"id":"448377","messageId":"xmqqilth2u28.fsf@gitster.g","threadId":"57221","inReplyTo":"20220214020827.1508706-1-sandals@crustytoothpaste.net","subject":"Re: [PATCH v2 0/2] Improvements to tests and docs for .gitattributes eol","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-02-14T18:15:43Z","receivedAt":"2022-02-14T18:15:51Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"brian m. carlson\" <sandals@crustytoothpaste.net> writes:\n\n> I was answering a question on StackOverflow recently about the\n> interaction between text=auto and eol, and someone pointed out to me\n> that what I had written, which was based on the documentation, was not\n> correct as of Git 2.10 (and more specifically 6523728499 (\"convert:\n> unify the \"auto\" handling of CRLF\", 2016-06-28)).\n>\n> When I set out to document the behavior correctly, I ran into the fact\n> that the tests, where I looked for examples of how this behaves, didn't\n> have any tests for some of these cases, and so I had some trouble\n> documenting this clearly and accurately.  So this series basically just\n> adds some tests for existing behavior so we don't change it (and so I\n> could figure out how it works) and then updates the documentation\n> accordingly.\n\nThis seems to be a replacement of the two-patch series that was\nmerged to 'master' at 8db2f665 (Merge branch 'bc/clarify-eol-attr',\n2022-02-11) and was merged to 'next' at dc1db4bd (Merge branch\n'bc/clarify-eol-attr' into next, 2022-02-04).  The changes seem to\nbe in the second step to update Documentation/gitattributes.txt and\nit needs to be made an incremental update.\n\nThanks.\n\n---- >8 -----\nFrom: brian m. carlson <sandals@crustytoothpaste.net>\nSubject: doc: clarify interaction between 'eol' and text=auto\n\nThe `eol` takes effect on text files only when the index has the\ncontents in LF line endings.  Paths with contents in CRLF line\nendings in the index may become dirty unless text=auto.\n\nSigned-off-by: brian m. carlson <sandals@crustytoothpaste.net>\nSigned-off-by: Junio C Hamano <gitster@pobox.com>\n---\n Documentation/gitattributes.txt | 11 ++++++-----\n 1 file changed, 6 insertions(+), 5 deletions(-)\n\ndiff --git c/Documentation/gitattributes.txt w/Documentation/gitattributes.txt\nindex 60984a4682..a71dad2674 100644\n--- c/Documentation/gitattributes.txt\n+++ w/Documentation/gitattributes.txt\n@@ -161,11 +161,12 @@ unspecified.\n \n This attribute sets a specific line-ending style to be used in the\n working directory.  This attribute has effect only if the `text`\n-attribute is set or unspecified, or if it is set to `auto` and the file\n-is detected as text.  Note that setting this attribute on paths which\n-are in the index with CRLF line endings may make the paths to be\n-considered dirty. Adding the path to the index again will normalize the\n-line endings in the index.\n+attribute is set or unspecified, or if it is set to `auto`, the file is\n+detected as text, and it is stored with LF endings in the index.  Note\n+that setting this attribute on paths which are in the index with CRLF\n+line endings may make the paths to be considered dirty unless\n+`text=auto` is set. Adding the path to the index again will normalize\n+the line endings in the index.\n \n Set to string value \"crlf\"::\n \n"},{"id":"448387","messageId":"20220214204631.mquj645jt5qajwku@tb-raspi4","threadId":"57221","inReplyTo":"xmqqilth2u28.fsf@gitster.g","subject":"Re: [PATCH v2 0/2] Improvements to tests and docs for .gitattributes eol","fromName":"Torsten B��gershausen","fromEmail":"tboegi@web.de","sentAt":"2022-02-14T20:46:32Z","receivedAt":"2022-02-14T20:56:31Z","isPatch":true,"sender":{"key":"tboegi@web.de","avatar":"https://avatars.githubusercontent.com/u/7138363?v=4"},"body":"[]\n> This seems to be a replacement of the two-patch series that was\n> merged to 'master' at 8db2f665 (Merge branch 'bc/clarify-eol-attr',\n> 2022-02-11) and was merged to 'next' at dc1db4bd (Merge branch\n> 'bc/clarify-eol-attr' into next, 2022-02-04).  The changes seem to\n> be in the second step to update Documentation/gitattributes.txt and\n> it needs to be made an incremental update.\n>\n> Thanks.\n>\n> ---- >8 -----\n> From: brian m. carlson <sandals@crustytoothpaste.net>\n> Subject: doc: clarify interaction between 'eol' and text=auto\n>\n> The `eol` takes effect on text files only when the index has the\n> contents in LF line endings.  Paths with contents in CRLF line\n> endings in the index may become dirty unless text=auto.\n\nThat is a nice, precise and short summary here in the commit message\nas well as the patch further down.\n\n>\n> Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>\n> Signed-off-by: Junio C Hamano <gitster@pobox.com>\n> ---\n>  Documentation/gitattributes.txt | 11 ++++++-----\n>  1 file changed, 6 insertions(+), 5 deletions(-)\n>\n> diff --git c/Documentation/gitattributes.txt w/Documentation/gitattributes.txt\n> index 60984a4682..a71dad2674 100644\n> --- c/Documentation/gitattributes.txt\n> +++ w/Documentation/gitattributes.txt\n> @@ -161,11 +161,12 @@ unspecified.\n>\n>  This attribute sets a specific line-ending style to be used in the\n>  working directory.  This attribute has effect only if the `text`\n> -attribute is set or unspecified, or if it is set to `auto` and the file\n> -is detected as text.  Note that setting this attribute on paths which\n> -are in the index with CRLF line endings may make the paths to be\n> -considered dirty. Adding the path to the index again will normalize the\n> -line endings in the index.\n> +attribute is set or unspecified, or if it is set to `auto`, the file is\n> +detected as text, and it is stored with LF endings in the index.  Note\n> +that setting this attribute on paths which are in the index with CRLF\n> +line endings may make the paths to be considered dirty unless\n> +`text=auto` is set. Adding the path to the index again will normalize\n> +the line endings in the index.\n>\n>  Set to string value \"crlf\"::\n>\n"},{"id":"448395","messageId":"xmqq8rud0ytj.fsf@gitster.g","threadId":"57221","inReplyTo":"20220214204631.mquj645jt5qajwku@tb-raspi4","subject":"Re: [PATCH v2 0/2] Improvements to tests and docs for .gitattributes eol","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-02-15T00:15:52Z","receivedAt":"2022-02-15T00:15:57Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Torsten Bögershausen <tboegi@web.de> writes:\n\n>> ---- >8 -----\n>> From: brian m. carlson <sandals@crustytoothpaste.net>\n>> Subject: doc: clarify interaction between 'eol' and text=auto\n>>\n>> The `eol` takes effect on text files only when the index has the\n>> contents in LF line endings.  Paths with contents in CRLF line\n>> endings in the index may become dirty unless text=auto.\n>\n> That is a nice, precise and short summary here in the commit message\n> as well as the patch further down.\n\nThanks.  Then let's queue it for 'next' and merge it down.\n\n>>\n>> Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>\n>> Signed-off-by: Junio C Hamano <gitster@pobox.com>\n>> ---\n>>  Documentation/gitattributes.txt | 11 ++++++-----\n>>  1 file changed, 6 insertions(+), 5 deletions(-)\n>>\n>> diff --git c/Documentation/gitattributes.txt w/Documentation/gitattributes.txt\n>> index 60984a4682..a71dad2674 100644\n>> --- c/Documentation/gitattributes.txt\n>> +++ w/Documentation/gitattributes.txt\n>> @@ -161,11 +161,12 @@ unspecified.\n>>\n>>  This attribute sets a specific line-ending style to be used in the\n>>  working directory.  This attribute has effect only if the `text`\n>> -attribute is set or unspecified, or if it is set to `auto` and the file\n>> -is detected as text.  Note that setting this attribute on paths which\n>> -are in the index with CRLF line endings may make the paths to be\n>> -considered dirty. Adding the path to the index again will normalize the\n>> -line endings in the index.\n>> +attribute is set or unspecified, or if it is set to `auto`, the file is\n>> +detected as text, and it is stored with LF endings in the index.  Note\n>> +that setting this attribute on paths which are in the index with CRLF\n>> +line endings may make the paths to be considered dirty unless\n>> +`text=auto` is set. Adding the path to the index again will normalize\n>> +the line endings in the index.\n>>\n>>  Set to string value \"crlf\"::\n>>\n"},{"id":"448411","messageId":"9ab7761a-ff63-f809-47af-033825e5779e@kdbg.org","threadId":"57221","inReplyTo":"xmqq8rud0ytj.fsf@gitster.g","subject":"Re: [PATCH v2 0/2] Improvements to tests and docs for .gitattributes eol","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2022-02-15T07:05:44Z","receivedAt":"2022-02-15T07:05:53Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 15.02.22 um 01:15 schrieb Junio C Hamano:\n> Torsten Bögershausen <tboegi@web.de> writes:\n> \n>>> ---- >8 -----\n>>> From: brian m. carlson <sandals@crustytoothpaste.net>\n>>> Subject: doc: clarify interaction between 'eol' and text=auto\n>>>\n>>> The `eol` takes effect on text files only when the index has the\n>>> contents in LF line endings.  Paths with contents in CRLF line\n>>> endings in the index may become dirty unless text=auto.\n>>\n>> That is a nice, precise and short summary here in the commit message\n>> as well as the patch further down.\n> \n> Thanks.  Then let's queue it for 'next' and merge it down.\n> \n>>>\n>>> Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>\n>>> Signed-off-by: Junio C Hamano <gitster@pobox.com>\n>>> ---\n>>>  Documentation/gitattributes.txt | 11 ++++++-----\n>>>  1 file changed, 6 insertions(+), 5 deletions(-)\n>>>\n>>> diff --git c/Documentation/gitattributes.txt w/Documentation/gitattributes.txt\n>>> index 60984a4682..a71dad2674 100644\n>>> --- c/Documentation/gitattributes.txt\n>>> +++ w/Documentation/gitattributes.txt\n>>> @@ -161,11 +161,12 @@ unspecified.\n>>>\n>>>  This attribute sets a specific line-ending style to be used in the\n>>>  working directory.  This attribute has effect only if the `text`\n>>> -attribute is set or unspecified, or if it is set to `auto` and the file\n>>> -is detected as text.  Note that setting this attribute on paths which\n>>> -are in the index with CRLF line endings may make the paths to be\n>>> -considered dirty. Adding the path to the index again will normalize the\n>>> -line endings in the index.\n>>> +attribute is set or unspecified, or if it is set to `auto`, the file is\n>>> +detected as text, and it is stored with LF endings in the index.  Note\n>>> +that setting this attribute on paths which are in the index with CRLF\n>>> +line endings may make the paths to be considered dirty unless\n>>> +`text=auto` is set. Adding the path to the index again will normalize\n>>> +the line endings in the index.\n\nSorry, I don't find this description clear at all due to the many 'or's\nand 'and's and no indication which parts belong together. The original\ntext was clear (but, of course, not helpful if it was wrong).\n\nI suggest to rewrite the paragraph into format with bullet points:\n\n   ... only if one of the following is true:\n\n  - is set and foo or bar\n  - is unspecified and either\n      - this\n      - or that\n  - is set to auto but not...\n\nor something along the lines. I can't propose actual text because I have\nno clue what the truth is.\n\n-- Hannes\n"},{"id":"448495","messageId":"YgwtMhuODDcVWEd6@camp.crustytoothpaste.net","threadId":"57221","inReplyTo":"9ab7761a-ff63-f809-47af-033825e5779e@kdbg.org","subject":"Re: [PATCH v2 0/2] Improvements to tests and docs for .gitattributes eol","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2022-02-15T22:46:10Z","receivedAt":"2022-02-15T22:46:15Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2022-02-15 at 07:05:44, Johannes Sixt wrote:\n> Sorry, I don't find this description clear at all due to the many 'or's\n> and 'and's and no indication which parts belong together. The original\n> text was clear (but, of course, not helpful if it was wrong).\n> \n> I suggest to rewrite the paragraph into format with bullet points:\n> \n>    ... only if one of the following is true:\n> \n>   - is set and foo or bar\n>   - is unspecified and either\n>       - this\n>       - or that\n>   - is set to auto but not...\n> \n> or something along the lines. I can't propose actual text because I have\n> no clue what the truth is.\n\nUnfortunately, the fact is that this behaviour is complicated.  I can\ntry a reroll with a bulleted list, though.\n-- \nbrian m. carlson (he/him or they/them)\nToronto, Ontario, CA\n"},{"id":"448552","messageId":"9ce63b16-cf75-3404-88cf-0623194db07b@kdbg.org","threadId":"57221","inReplyTo":"YgwtMhuODDcVWEd6@camp.crustytoothpaste.net","subject":"Re: [PATCH v2 0/2] Improvements to tests and docs for .gitattributes eol","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2022-02-16T07:00:24Z","receivedAt":"2022-02-16T07:43:35Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 15.02.22 um 23:46 schrieb brian m. carlson:\n> On 2022-02-15 at 07:05:44, Johannes Sixt wrote:\n>> Sorry, I don't find this description clear at all due to the many 'or's\n>> and 'and's and no indication which parts belong together. The original\n>> text was clear (but, of course, not helpful if it was wrong).\n>>\n>> I suggest to rewrite the paragraph into format with bullet points:\n>>\n>>    ... only if one of the following is true:\n>>\n>>   - is set and foo or bar\n>>   - is unspecified and either\n>>       - this\n>>       - or that\n>>   - is set to auto but not...\n>>\n>> or something along the lines. I can't propose actual text because I have\n>> no clue what the truth is.\n> \n> Unfortunately, the fact is that this behaviour is complicated.  I can\n> try a reroll with a bulleted list, though.\n\nJust so you know where my confusion arises from: Your updated text has\nthe structure (as I read it)\n\n   if ... set or unspecified or if auto then ... detected ... and LF\n\nIt is unclear whether the 'then' conditions apply only to 'if auto'.\nEven if the additional 'if' in the middle makes me think that the\n'then's apply only to the 'auto' case, it is sufficently vage because in\nmy mental model there is not much difference between an 'unset' and a\nset-to-'auto' attribute, and I wonder why the 'then's should not apply\nto the 'unset' case as well.\n\nMoreover, after re-reading the text, I notice that text may be read as\n\"this attribute has an effect only if <conditions>\" where <conditions>\nbasically means \"always except for when the 'if auto' case is not met\",\nright? Would it perhaps be better to write \"has no effect if <very\nspecific condition>\"?\n\n-- Hannes\n"},{"id":"448576","messageId":"YgzRyKZwsPw6rTyT@camp.crustytoothpaste.net","threadId":"57221","inReplyTo":"9ce63b16-cf75-3404-88cf-0623194db07b@kdbg.org","subject":"Re: [PATCH v2 0/2] Improvements to tests and docs for .gitattributes eol","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2022-02-16T10:28:24Z","receivedAt":"2022-02-16T10:28:50Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2022-02-16 at 07:00:24, Johannes Sixt wrote:\n> Just so you know where my confusion arises from: Your updated text has\n> the structure (as I read it)\n> \n>    if ... set or unspecified or if auto then ... detected ... and LF\n> \n> It is unclear whether the 'then' conditions apply only to 'if auto'.\n> Even if the additional 'if' in the middle makes me think that the\n> 'then's apply only to the 'auto' case, it is sufficently vage because in\n> my mental model there is not much difference between an 'unset' and a\n> set-to-'auto' attribute, and I wonder why the 'then's should not apply\n> to the 'unset' case as well.\n> \n> Moreover, after re-reading the text, I notice that text may be read as\n> \"this attribute has an effect only if <conditions>\" where <conditions>\n> basically means \"always except for when the 'if auto' case is not met\",\n> right? Would it perhaps be better to write \"has no effect if <very\n> specific condition>\"?\n\nThe situation is that eol is in effect if and only if:\n\n* text is set;\n* text is unspecified; or\n* text is auto, the file is detected as text, and the file has LF line\n  endings in the index.\n\nAlternately, it has no effect if and only if:\n\n* text is unset;\n* text is auto and the file is detected as binary; or\n* text is auto and the file is detected as text and has CRLF line\n  endings.\n\nI'm not sure one reads significantly easier than the other.  I slightly\nprefer the former because it has fewer conditions with multiple nested\nentries, though.\n-- \nbrian m. carlson (he/him or they/them)\nToronto, Ontario, CA\n"},{"id":"448587","messageId":"20220216115239.uo2ie3flaqo3nf2d@tb-raspi4","threadId":"57221","inReplyTo":"YgzRyKZwsPw6rTyT@camp.crustytoothpaste.net","subject":"Re: [PATCH v2 0/2] Improvements to tests and docs for .gitattributes eol","fromName":"Torsten B��gershausen","fromEmail":"tboegi@web.de","sentAt":"2022-02-16T11:52:39Z","receivedAt":"2022-02-16T11:52:58Z","isPatch":true,"sender":{"key":"tboegi@web.de","avatar":"https://avatars.githubusercontent.com/u/7138363?v=4"},"body":"On Wed, Feb 16, 2022 at 10:28:24AM +0000, brian m. carlson wrote:\n> On 2022-02-16 at 07:00:24, Johannes Sixt wrote:\n> > Just so you know where my confusion arises from: Your updated text has\n> > the structure (as I read it)\n> >\n> >    if ... set or unspecified or if auto then ... detected ... and LF\n> >\n> > It is unclear whether the 'then' conditions apply only to 'if auto'.\n> > Even if the additional 'if' in the middle makes me think that the\n> > 'then's apply only to the 'auto' case, it is sufficently vage because in\n> > my mental model there is not much difference between an 'unset' and a\n> > set-to-'auto' attribute, and I wonder why the 'then's should not apply\n> > to the 'unset' case as well.\n> >\n> > Moreover, after re-reading the text, I notice that text may be read as\n> > \"this attribute has an effect only if <conditions>\" where <conditions>\n> > basically means \"always except for when the 'if auto' case is not met\",\n> > right? Would it perhaps be better to write \"has no effect if <very\n> > specific condition>\"?\n>\n> The situation is that eol is in effect if and only if:\n\nWell written\n\n>\n> * text is set;\n> * text is unspecified; or\n> * text is auto, the file is detected as text, and the file has LF line\n>   endings in the index.\n>\n> Alternately, it has no effect if and only if:\n>\n> * text is unset;\n> * text is auto and the file is detected as binary; or\n> * text is auto and the file is detected as text and has CRLF line\n>   endings.\n... CRLF line endings in the index.\n                      ^^^^^^^^^^^^\n\nOne of the reasons that the eol attribute is not 100% well-specified\nis that people should use the eol attribute together with text.\n\nEither\ntext=auto eol=crlf\nor\ntext=auto eol=lf\nor\ntext eol=crlf\nor\ntext eol=lf\n\nOlder git versions did treat\n* text=auto\n* eol=crlf\n\nThe same as\n* text eol=crlf\nWhich did corrupt binary files.\n\nNever git versions treat\n* text=auto\n* eol=crlf\nas\n* text=auto eol=crlf\nin the sense that only auto-detected text files are converted,\nif they had not been commited with crlf before.\n\nIn that sense I feel that the short form\neol=crlf\nshould be avoided\n\n>\n> I'm not sure one reads significantly easier than the other.  I slightly\n> prefer the former because it has fewer conditions with multiple nested\n> entries, though.\n> --\n> brian m. carlson (he/him or they/them)\n> Toronto, Ontario, CA\n\n\n"},{"id":"448628","messageId":"108f009b-daa3-4ef4-755e-7c9f86f898c5@kdbg.org","threadId":"57221","inReplyTo":"YgzRyKZwsPw6rTyT@camp.crustytoothpaste.net","subject":"Re: [PATCH v2 0/2] Improvements to tests and docs for .gitattributes eol","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2022-02-16T19:02:02Z","receivedAt":"2022-02-16T19:02:16Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 16.02.22 um 11:28 schrieb brian m. carlson:\n> The situation is that eol is in effect if and only if:\n> \n> * text is set;\n> * text is unspecified; or\n> * text is auto, the file is detected as text, and the file has LF line\n>   endings in the index.\n> \n> Alternately, it has no effect if and only if:\n> \n> * text is unset;\n> * text is auto and the file is detected as binary; or\n> * text is auto and the file is detected as text and has CRLF line\n>   endings.\n> \n> I'm not sure one reads significantly easier than the other.  I slightly\n> prefer the former because it has fewer conditions with multiple nested\n> entries, though.\n\nI agree that the first version is easier to understand.\n\n-- Hannes\n"},{"id":"471427","messageId":"20230203125920.751-1-philipoakley@iee.email","threadId":"57221","inReplyTo":"20220216115239.uo2ie3flaqo3nf2d@tb-raspi4","subject":"[PATCH] .gitattributes: include `text` attribute for eol attributes","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.email","sentAt":"2023-02-03T12:59:20Z","receivedAt":"2023-02-03T12:59:35Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"The standard advice for text file eol endings in the .gitattributes file\nwas updated in e28eae3184 (gitattributes: Document the unified \"auto\"\nhandling, 2016-08-26) with a recent clarification in 8c591dbfce (docs:\ncorrect documentation about eol attribute, 2022-01-11), with a follow\nup comment by the original author in [1] confirming the use of the eol\nattribute in conjunction with the text attribute.\n\nUpdate Git's .gitattributes file to reflect our own advice.\n\n[1] https://lore.kernel.org/git/?q=%3C20220216115239.uo2ie3flaqo3nf2d%40tb-raspi4%3E.\n\nSigned-off-by: Philip Oakley <philipoakley@iee.email>\n---\n\nI was catching up on last year's back emails, and had saved those on\neol and text conversion, and was prompted by Torsten's [1] to check\nmy .gitattribute files, only to discover, we aren't providing a good\nexample to others. Let's fix that. \n\n\n .gitattributes | 22 +++++++++++-----------\n 1 file changed, 11 insertions(+), 11 deletions(-)\n\ndiff --git a/.gitattributes b/.gitattributes\nindex b0044cf272..158c3d45c4 100644\n--- a/.gitattributes\n+++ b/.gitattributes\n@@ -1,17 +1,17 @@\n * whitespace=!indent,trail,space\n *.[ch] whitespace=indent,trail,space diff=cpp\n-*.sh whitespace=indent,trail,space eol=lf\n-*.perl eol=lf diff=perl\n-*.pl eof=lf diff=perl\n-*.pm eol=lf diff=perl\n-*.py eol=lf diff=python\n-*.bat eol=crlf\n+*.sh whitespace=indent,trail,space text eol=lf\n+*.perl text eol=lf diff=perl\n+*.pl text eof=lf diff=perl\n+*.pm text eol=lf diff=perl\n+*.py text eol=lf diff=python\n+*.bat text eol=crlf\n CODE_OF_CONDUCT.md -whitespace\n-/Documentation/**/*.txt eol=lf\n-/command-list.txt eol=lf\n-/GIT-VERSION-GEN eol=lf\n-/mergetools/* eol=lf\n-/t/oid-info/* eol=lf\n+/Documentation/**/*.txt text eol=lf\n+/command-list.txt text eol=lf\n+/GIT-VERSION-GEN text eol=lf\n+/mergetools/* text eol=lf\n+/t/oid-info/* text eol=lf\n /Documentation/git-merge.txt conflict-marker-size=32\n /Documentation/gitk.txt conflict-marker-size=32\n /Documentation/user-manual.txt conflict-marker-size=32\n-- \n2.39.1.windows.1\n\n"},{"id":"471432","messageId":"230203.86k00yc167.gmgdl@evledraar.gmail.com","threadId":"57221","inReplyTo":"20230203125920.751-1-philipoakley@iee.email","subject":"Re: [PATCH] .gitattributes: include `text` attribute for eol attributes","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2023-02-03T13:40:13Z","receivedAt":"2023-02-03T13:46:17Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Fri, Feb 03 2023, Philip Oakley wrote:\n\n> The standard advice for text file eol endings in the .gitattributes file\n> was updated in e28eae3184 (gitattributes: Document the unified \"auto\"\n> handling, 2016-08-26) with a recent clarification in 8c591dbfce (docs:\n> correct documentation about eol attribute, 2022-01-11), with a follow\n> up comment by the original author in [1] confirming the use of the eol\n> attribute in conjunction with the text attribute.\n>\n> Update Git's .gitattributes file to reflect our own advice.\n>\n> [1] https://lore.kernel.org/git/?q=%3C20220216115239.uo2ie3flaqo3nf2d%40tb-raspi4%3E.\n>\n> Signed-off-by: Philip Oakley <philipoakley@iee.email>\n> ---\n>\n> I was catching up on last year's back emails, and had saved those on\n> eol and text conversion, and was prompted by Torsten's [1] to check\n> my .gitattribute files, only to discover, we aren't providing a good\n> example to others. Let's fix that. \n\nThis seems sensible, but if we're taking the churn of changing these\nlines maybe it's worth moving or adjusting some of this while-at-it.\n\nIn particular:\n\n>  .gitattributes | 22 +++++++++++-----------\n>  1 file changed, 11 insertions(+), 11 deletions(-)\n>\n> diff --git a/.gitattributes b/.gitattributes\n> index b0044cf272..158c3d45c4 100644\n> --- a/.gitattributes\n> +++ b/.gitattributes\n> @@ -1,17 +1,17 @@\n>  * whitespace=!indent,trail,space\n>  *.[ch] whitespace=indent,trail,space diff=cpp\n> -*.sh whitespace=indent,trail,space eol=lf\n> -*.perl eol=lf diff=perl\n> -*.pl eof=lf diff=perl\n> -*.pm eol=lf diff=perl\n> -*.py eol=lf diff=python\n> -*.bat eol=crlf\n\nWe don't have any *.bat in-tree except in compat/vcbuild/. Shouldn't we\njust create a compat/vcbuild/.gitattributes? This was added in\nhttps://lore.kernel.org/git/pull.149.v2.git.gitgitgadget@gmail.com/; so\nit's for those specific files.\n\n>  CODE_OF_CONDUCT.md -whitespace\n> -/Documentation/**/*.txt eol=lf\n> -/command-list.txt eol=lf\n> -/GIT-VERSION-GEN eol=lf\n> -/mergetools/* eol=lf\n> -/t/oid-info/* eol=lf\n> +/Documentation/**/*.txt text eol=lf\n\nWe have a Documentation/.gitattributes, shouldn't we move this\nDocumentation/ rule there instead?\n\n> +/command-list.txt text eol=lf\n> +/GIT-VERSION-GEN text eol=lf\n> +/mergetools/* text eol=lf\n\n..maybe we should create a mergetools/.gitattributes & move this there?\n\n> +/t/oid-info/* text eol=lf\n\nDitto t/.gitattributes and thist/oid-info/ rule.\n\n>  /Documentation/git-merge.txt conflict-marker-size=32\n>  /Documentation/gitk.txt conflict-marker-size=32\n>  /Documentation/user-manual.txt conflict-marker-size=32\n\n"},{"id":"471440","messageId":"43d807f1-07f0-c0a1-e6ae-bdb5df73a565@iee.email","threadId":"57221","inReplyTo":"230203.86k00yc167.gmgdl@evledraar.gmail.com","subject":"Re: [PATCH] .gitattributes: include `text` attribute for eol attributes","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.email","sentAt":"2023-02-03T16:43:09Z","receivedAt":"2023-02-03T16:43:20Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"On 03/02/2023 13:40, Ævar Arnfjörð Bjarmason wrote:\n> On Fri, Feb 03 2023, Philip Oakley wrote:\n>\n>> The standard advice for text file eol endings in the .gitattributes file\n>> was updated in e28eae3184 (gitattributes: Document the unified \"auto\"\n>> handling, 2016-08-26) with a recent clarification in 8c591dbfce (docs:\n>> correct documentation about eol attribute, 2022-01-11), with a follow\n>> up comment by the original author in [1] confirming the use of the eol\n>> attribute in conjunction with the text attribute.\n>>\n>> Update Git's .gitattributes file to reflect our own advice.\n>>\n>> [1] https://lore.kernel.org/git/?q=%3C20220216115239.uo2ie3flaqo3nf2d%40tb-raspi4%3E.\n>>\n>> Signed-off-by: Philip Oakley <philipoakley@iee.email>\n>> ---\n>>\n>> I was catching up on last year's back emails, and had saved those on\n>> eol and text conversion, and was prompted by Torsten's [1] to check\n>> my .gitattribute files, only to discover, we aren't providing a good\n>> example to others. Let's fix that. \n> This seems sensible, but if we're taking the churn of changing these\n> lines maybe it's worth moving or adjusting some of this while-at-it.\n\nSeems reasonable.\nI've added in dscho (cc) for consideration of the Git for Windows\nviewpoint..\n>\n> In particular:\n>\n>>  .gitattributes | 22 +++++++++++-----------\n>>  1 file changed, 11 insertions(+), 11 deletions(-)\n>>\n>> diff --git a/.gitattributes b/.gitattributes\n>> index b0044cf272..158c3d45c4 100644\n>> --- a/.gitattributes\n>> +++ b/.gitattributes\n>> @@ -1,17 +1,17 @@\n>>  * whitespace=!indent,trail,space\n>>  *.[ch] whitespace=indent,trail,space diff=cpp\n>> -*.sh whitespace=indent,trail,space eol=lf\n>> -*.perl eol=lf diff=perl\n>> -*.pl eof=lf diff=perl\n>> -*.pm eol=lf diff=perl\n>> -*.py eol=lf diff=python\n>> -*.bat eol=crlf\n> We don't have any *.bat in-tree except in compat/vcbuild/. Shouldn't we\n> just create a compat/vcbuild/.gitattributes? This was added in\n> https://lore.kernel.org/git/pull.149.v2.git.gitgitgadget@gmail.com/; so\n> it's for those specific files.\n\nsensible\n>>  CODE_OF_CONDUCT.md -whitespace\n\nMaybe the CODE_OF_CONDUCT.md should also be marked as text?\n\n>> -/Documentation/**/*.txt eol=lf\n>> -/command-list.txt eol=lf\n>> -/GIT-VERSION-GEN eol=lf\n>> -/mergetools/* eol=lf\n>> -/t/oid-info/* eol=lf\n>> +/Documentation/**/*.txt text eol=lf\n> We have a Documentation/.gitattributes, shouldn't we move this\n> Documentation/ rule there instead?\n\nok\n>\n>> +/command-list.txt text eol=lf\n>> +/GIT-VERSION-GEN text eol=lf\n>> +/mergetools/* text eol=lf\n> ..maybe we should create a mergetools/.gitattributes & move this there?\n\nperhaps. There are probably sufficient listed there to make it work it.\n>\n>> +/t/oid-info/* text eol=lf\n> Ditto t/.gitattributes and this t/oid-info/ rule.\n>\n>>  /Documentation/git-merge.txt conflict-marker-size=32\n>>  /Documentation/gitk.txt conflict-marker-size=32\n>>  /Documentation/user-manual.txt conflict-marker-size=32\nI'll hold a day or so for any extra contributions.\n\nPhilip\n"},{"id":"471474","messageId":"20230204080348.vqrxsk7ze6bcz4nf@tb-raspi4","threadId":"57221","inReplyTo":"20230203125920.751-1-philipoakley@iee.email","subject":"Re: [PATCH] .gitattributes: include `text` attribute for eol attributes","fromName":"Torsten Bögershausen","fromEmail":"tboegi@web.de","sentAt":"2023-02-04T08:03:48Z","receivedAt":"2023-02-04T08:09:19Z","isPatch":true,"sender":{"key":"tboegi@web.de","avatar":"https://avatars.githubusercontent.com/u/7138363?v=4"},"body":"On Fri, Feb 03, 2023 at 12:59:20PM +0000, Philip Oakley wrote:\n> The standard advice for text file eol endings in the .gitattributes file\n> was updated in e28eae3184 (gitattributes: Document the unified \"auto\"\n> handling, 2016-08-26) with a recent clarification in 8c591dbfce (docs:\n> correct documentation about eol attribute, 2022-01-11), with a follow\n> up comment by the original author in [1] confirming the use of the eol\n> attribute in conjunction with the text attribute.\n>\n> Update Git's .gitattributes file to reflect our own advice.\n>\n> [1] https://lore.kernel.org/git/?q=%3C20220216115239.uo2ie3flaqo3nf2d%40tb-raspi4%3E.\n>\n> Signed-off-by: Philip Oakley <philipoakley@iee.email>\n> ---\n>\n> I was catching up on last year's back emails, and had saved those on\n> eol and text conversion, and was prompted by Torsten's [1] to check\n> my .gitattribute files, only to discover, we aren't providing a good\n> example to others. Let's fix that.\n>\n>\n>  .gitattributes | 22 +++++++++++-----------\n>  1 file changed, 11 insertions(+), 11 deletions(-)\n>\n> diff --git a/.gitattributes b/.gitattributes\n> index b0044cf272..158c3d45c4 100644\n> --- a/.gitattributes\n> +++ b/.gitattributes\n> @@ -1,17 +1,17 @@\n>  * whitespace=!indent,trail,space\n>  *.[ch] whitespace=indent,trail,space diff=cpp\n> -*.sh whitespace=indent,trail,space eol=lf\n> -*.perl eol=lf diff=perl\n> -*.pl eof=lf diff=perl\n> -*.pm eol=lf diff=perl\n> -*.py eol=lf diff=python\n> -*.bat eol=crlf\n> +*.sh whitespace=indent,trail,space text eol=lf\n> +*.perl text eol=lf diff=perl\n> +*.pl text eof=lf diff=perl\n> +*.pm text eol=lf diff=perl\n\n> +*.py text eol=lf diff=python\nIn my eperience python doesn't care about CRLF or LF, both work.\n\nAnd it is stated here:\nhttps://docs.python.org/3/reference/lexical_analysis.html?highlight=line%20endings\n\nIn that sense we can loosen the eol=lf, and use CRLF under\nWindows and LF elsewhere. This will make e.g. notepad users happy:\n\n> +*.py text  diff=python\n\n\n"},{"id":"471613","messageId":"xmqqwn4u4fvk.fsf@gitster.g","threadId":"57221","inReplyTo":"20230203125920.751-1-philipoakley@iee.email","subject":"Re: [PATCH] .gitattributes: include `text` attribute for eol attributes","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2023-02-06T21:56:47Z","receivedAt":"2023-02-06T21:56:53Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Philip Oakley <philipoakley@iee.email> writes:\n\n> The standard advice for text file eol endings in the .gitattributes file\n> was updated in e28eae3184 (gitattributes: Document the unified \"auto\"\n> handling, 2016-08-26) with a recent clarification in 8c591dbfce (docs:\n> correct documentation about eol attribute, 2022-01-11), with a follow\n> up comment by the original author in [1] confirming the use of the eol\n> attribute in conjunction with the text attribute.\n>\n> Update Git's .gitattributes file to reflect our own advice.\n>\n> [1] https://lore.kernel.org/git/?q=%3C20220216115239.uo2ie3flaqo3nf2d%40tb-raspi4%3E.\n>\n> Signed-off-by: Philip Oakley <philipoakley@iee.email>\n> ---\n>\n> I was catching up on last year's back emails, and had saved those on\n> eol and text conversion, and was prompted by Torsten's [1] to check\n> my .gitattribute files, only to discover, we aren't providing a good\n> example to others. Let's fix that. \n\nThanks.  Let's keep this single step as a pure \"no, eol=lf alone is\nnot how we recommend you to mark a text file, and here is the fix\"\nchange.\n\nThere may be other things people might want to do on top of\nthis change, but they can be done on top.\n\nWill queue.  Thanks.\n\n\n>\n>\n>  .gitattributes | 22 +++++++++++-----------\n>  1 file changed, 11 insertions(+), 11 deletions(-)\n>\n> diff --git a/.gitattributes b/.gitattributes\n> index b0044cf272..158c3d45c4 100644\n> --- a/.gitattributes\n> +++ b/.gitattributes\n> @@ -1,17 +1,17 @@\n>  * whitespace=!indent,trail,space\n>  *.[ch] whitespace=indent,trail,space diff=cpp\n> -*.sh whitespace=indent,trail,space eol=lf\n> -*.perl eol=lf diff=perl\n> -*.pl eof=lf diff=perl\n> -*.pm eol=lf diff=perl\n> -*.py eol=lf diff=python\n> -*.bat eol=crlf\n> +*.sh whitespace=indent,trail,space text eol=lf\n> +*.perl text eol=lf diff=perl\n> +*.pl text eof=lf diff=perl\n> +*.pm text eol=lf diff=perl\n> +*.py text eol=lf diff=python\n> +*.bat text eol=crlf\n>  CODE_OF_CONDUCT.md -whitespace\n> -/Documentation/**/*.txt eol=lf\n> -/command-list.txt eol=lf\n> -/GIT-VERSION-GEN eol=lf\n> -/mergetools/* eol=lf\n> -/t/oid-info/* eol=lf\n> +/Documentation/**/*.txt text eol=lf\n> +/command-list.txt text eol=lf\n> +/GIT-VERSION-GEN text eol=lf\n> +/mergetools/* text eol=lf\n> +/t/oid-info/* text eol=lf\n>  /Documentation/git-merge.txt conflict-marker-size=32\n>  /Documentation/gitk.txt conflict-marker-size=32\n>  /Documentation/user-manual.txt conflict-marker-size=32\n"}]}