git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH v2 0/2] Improvements to tests and docs for .gitattributes eol

From
Torsten B��gershausen <tboegi@web.de>
Date
Feb 16, 2022, 11:52 UTC
Message-ID
<20220216115239.uo2ie3flaqo3nf2d@tb-raspi4>
In-Reply-To
<YgzRyKZwsPw6rTyT@camp.crustytoothpaste.net>
On Wed, Feb 16, 2022 at 10:28:24AM +0000, brian m. carlson wrote:
Show 20 quoted lines
> On 2022-02-16 at 07:00:24, Johannes Sixt wrote:
> > Just so you know where my confusion arises from: Your updated text has
> > the structure (as I read it)
> >
> >    if ... set or unspecified or if auto then ... detected ... and LF
> >
> > It is unclear whether the 'then' conditions apply only to 'if auto'.
> > Even if the additional 'if' in the middle makes me think that the
> > 'then's apply only to the 'auto' case, it is sufficently vage because in
> > my mental model there is not much difference between an 'unset' and a
> > set-to-'auto' attribute, and I wonder why the 'then's should not apply
> > to the 'unset' case as well.
> >
> > Moreover, after re-reading the text, I notice that text may be read as
> > "this attribute has an effect only if <conditions>" where <conditions>
> > basically means "always except for when the 'if auto' case is not met",
> > right? Would it perhaps be better to write "has no effect if <very
> > specific condition>"?
>
> The situation is that eol is in effect if and only if:
Well written
Show 12 quoted lines
>
> * text is set;
> * text is unspecified; or
> * text is auto, the file is detected as text, and the file has LF line
>   endings in the index.
>
> Alternately, it has no effect if and only if:
>
> * text is unset;
> * text is auto and the file is detected as binary; or
> * text is auto and the file is detected as text and has CRLF line
>   endings.
... CRLF line endings in the index.
                      ^^^^^^^^^^^^

One of the reasons that the eol attribute is not 100% well-specified is that people should use the eol attribute together with text.

Either text=auto eol=crlf or text=auto eol=lf or text eol=crlf or text eol=lf

Older git versions did treat
* text=auto
* eol=crlf
The same as
* text eol=crlf
Which did corrupt binary files.
Never git versions treat
* text=auto
* eol=crlf
as
* text=auto eol=crlf
in the sense that only auto-detected text files are converted,
if they had not been commited with crlf before.

In that sense I feel that the short form eol=crlf should be avoided

Show 7 quoted lines
>
> I'm not sure one reads significantly easier than the other.  I slightly
> prefer the former because it has fewer conditions with multiple nested
> entries, though.
> --
> brian m. carlson (he/him or they/them)
> Toronto, Ontario, CA
Previous: brian m. carlsonNext: Philip Oakley
Message 18 of 24 in “Improvements to tests and docs for .gitattributes eol”
  1. 0/2 Improvements to tests and docs for .gitattributes eolbrian m. carlson, Jan 11, 2022
  2. 1/2 t0027: add tests for eol without text in .gitattributesbrian m. carlson, Jan 11, 2022
  3. 2/2 docs: correct documentation about eol attributebrian m. carlson, Jan 11, 2022
  4. Torsten B��gershausenJan 11, 2022
  5. brian m. carlsonJan 11, 2022
  6. Torsten B��gershausenJan 12, 2022
  7. 0/2 Improvements to tests and docs for .gitattributes eolbrian m. carlson, Feb 14, 2022
  8. 2/2 docs: correct documentation about eol attributebrian m. carlson, Feb 14, 2022
  9. 1/2 t0027: add tests for eol without text in .gitattributesbrian m. carlson, Feb 14, 2022
  10. Derrick StoleeFeb 14, 2022
  11. Junio C HamanoFeb 14, 2022
  12. Torsten B��gershausenFeb 14, 2022
  13. Junio C HamanoFeb 15, 2022
  14. Johannes SixtFeb 15, 2022
  15. brian m. carlsonFeb 15, 2022
  16. Johannes SixtFeb 16, 2022
  17. brian m. carlsonFeb 16, 2022
  18. Torsten B��gershausenFeb 16, 2022
  19. .gitattributes: include `text` attribute for eol attributesPhilip Oakley, Feb 3, 2023
  20. Ævar Arnfjörð BjarmasonFeb 3, 2023
  21. Philip OakleyFeb 3, 2023
  22. Torsten BögershausenFeb 4, 2023
  23. Junio C HamanoFeb 6, 2023
  24. Johannes SixtFeb 16, 2022

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.