| Message ID | 20220111021507.531736-3-sandals@crustytoothpaste.net (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | 8c591dbfcef9b4d40cfae7f675a2c99a0e925157 |
| Headers | show |
| Series | Improvements to tests and docs for .gitattributes eol | expand |
Hej Brian, thanks for digging into this. Could you be so kind to send the stackoverflow issue ? (You can send it to me only) I have some comments/questions, out of my head. On Tue, Jan 11, 2022 at 02:15:07AM +0000, brian m. carlson wrote: > The documentation for the eol attribute states that it is "effectively > setting the text attribute". > Let's avoid confusing users (and the present author when trying to > describe Git's behavior to others) by clearly documenting in which > cases the "eol" attribute has effect. > > Specifically, the attribute always has an effect unless the file is > explicitly set as -text, or the file is set as text=auto and the file is > detected as binary. > > Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> > --- > Documentation/gitattributes.txt | 11 ++++++----- > 1 file changed, 6 insertions(+), 5 deletions(-) > > diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt > index 83fd4e19a4..60984a4682 100644 > --- a/Documentation/gitattributes.txt > +++ b/Documentation/gitattributes.txt > @@ -160,11 +160,12 @@ unspecified. > ^^^^^ > > This attribute sets a specific line-ending style to be used in the > -working directory. It enables end-of-line conversion without any > -content checks, effectively setting the `text` attribute. Note that > -setting this attribute on paths which are in the index with CRLF line > -endings may make the paths to be considered dirty. Adding the path to > -the index again will normalize the line endings in the index. > +working directory. This attribute has effect only if the `text` > +attribute is set or unspecified, or if it is set to `auto` and the file > +is detected as text. > Note that setting this attribute on paths which > +are in the index with CRLF line endings may make the paths to be > +considered dirty. Adding the path to the index again will normalize the > +line endings in the index. I think that this can be loosened as well. And, beside this, the "dirty" warning about setting attributes could be written as part of the "text" attribute as well. I dunno. Here is a possible suggestion: Note that setting this attribute on paths which are in the index with CRLF line endings may make the paths to be considered dirty - unless "text=auto" is set. `git ls-files --eol` can be used to check the "line ending status". Adding the path to the index again will normalize the line endings in the index. > > Set to string value "crlf":: >
On 2022-01-11 at 18:30:03, Torsten Bögershausen wrote: > Hej Brian, > thanks for digging into this. > > Could you be so kind to send the stackoverflow issue ? > (You can send it to me only) I'll just post it here publicly, since I think there's value to folks seeing what questions users have: https://stackoverflow.com/questions/70633469/what-is-the-difference-between-text-auto-and-text-auto-eol-lf/70636508? > On Tue, Jan 11, 2022 at 02:15:07AM +0000, brian m. carlson wrote: > > Note that setting this attribute on paths which > > +are in the index with CRLF line endings may make the paths to be > > +considered dirty. Adding the path to the index again will normalize the > > +line endings in the index. > > I think that this can be loosened as well. And, beside this, the "dirty" > warning about setting attributes could be written as part of the "text" > attribute as well. I dunno. Here is a possible suggestion: > > > Note that setting this attribute on paths which are in the index with CRLF > line endings may make the paths to be considered dirty - unless "text=auto" > is set. `git ls-files --eol` can be used to check the "line ending status". > Adding the path to the index again will normalize the line endings in the index. I'm not sure that's correct, though. The problem is if the file is detected as text, which it might well be if text=auto is set. Or am I not understanding something correctly?
On Tue, Jan 11, 2022 at 10:40:47PM +0000, brian m. carlson wrote: > On 2022-01-11 at 18:30:03, Torsten B??gershausen wrote: > > Hej Brian, > > thanks for digging into this. > > > > Could you be so kind to send the stackoverflow issue ? > > (You can send it to me only) > > I'll just post it here publicly, since I think there's value to folks > seeing what questions users have: Thanks - Please see the comments inline, as usual. > > https://stackoverflow.com/questions/70633469/what-is-the-difference-between-text-auto-and-text-auto-eol-lf/70636508? To pick up the question here: I was reading about the .gitattributes file and the rule to force line endings in some tutorials it's written like * text=auto and in some others, it's like * text=auto eol=lf at the first line of the file. Are there any differences? what does the first one exactly do? Does it even force any line endings? [] Yes, there are differences. The line * text=auto will make sure that all by-Git-as-text-files-detected files will be commited with LF into the repo. CRLF in the working tree will become LF in the repo. When the files are checkout, the line endings depend on local git config settings: core.autocrlf=true will give CRLF core.autocrlf=input will give LF When core.autocrlf is false (or unset) git looks at core.eol: core.eol=crlf gives CRLF core.eol=lf gives LF core.eol unset (or native) will use the the native line endings, CRLF on Windows, LF everywhere else. -------------- Let's look at * text=auto eol=lf Here Git does not look at any local config variables. All files will be checkout out with LF, even on Windows. > > > On Tue, Jan 11, 2022 at 02:15:07AM +0000, brian m. carlson wrote: > > > Note that setting this attribute on paths which > > > +are in the index with CRLF line endings may make the paths to be > > > +considered dirty. Adding the path to the index again will normalize the > > > +line endings in the index. > > > > I think that this can be loosened as well. And, beside this, the "dirty" > > warning about setting attributes could be written as part of the "text" > > attribute as well. I dunno. Here is a possible suggestion: > > > > > > Note that setting this attribute on paths which are in the index with CRLF > > line endings may make the paths to be considered dirty - unless "text=auto" > > is set. `git ls-files --eol` can be used to check the "line ending status". > > Adding the path to the index again will normalize the line endings in the index. > > I'm not sure that's correct, though. The problem is if the file is > detected as text, which it might well be if text=auto is set. Or am I > not understanding something correctly? Which problem are we talking about ? Files that once had been commited with CRLF into the repo are now considered dirty? The "new safer autocrlf-handling" will not try to normalize them when text=auto is specified. They keep their existing line endings at checkout or checkin. I hope this makes sense ?
diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt index 83fd4e19a4..60984a4682 100644 --- a/Documentation/gitattributes.txt +++ b/Documentation/gitattributes.txt @@ -160,11 +160,12 @@ unspecified. ^^^^^ This attribute sets a specific line-ending style to be used in the -working directory. It enables end-of-line conversion without any -content checks, effectively setting the `text` attribute. Note that -setting this attribute on paths which are in the index with CRLF line -endings may make the paths to be considered dirty. Adding the path to -the index again will normalize the line endings in the index. +working directory. This attribute has effect only if the `text` +attribute is set or unspecified, or if it is set to `auto` and the file +is detected as text. Note that setting this attribute on paths which +are in the index with CRLF line endings may make the paths to be +considered dirty. Adding the path to the index again will normalize the +line endings in the index. Set to string value "crlf"::
The documentation for the eol attribute states that it is "effectively setting the text attribute". However, this implies that it forces the text attribute to always be set, which has not been the case since 6523728499 ("convert: unify the "auto" handling of CRLF", 2016-06-28). Let's avoid confusing users (and the present author when trying to describe Git's behavior to others) by clearly documenting in which cases the "eol" attribute has effect. Specifically, the attribute always has an effect unless the file is explicitly set as -text, or the file is set as text=auto and the file is detected as binary. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> --- Documentation/gitattributes.txt | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-)