Re: [PATCH 2/2] docs: correct documentation about eol attribute

From: Torsten B��gershausen <tboegi@web.de>
Date: Jan 12, 2022, 15:16 UTC
Message-ID: <20220112151657.4yy7q6pk54v4w2eh@tb-raspi4>
In-Reply-To: <Yd4Hb/bxvJZkJP7P@camp.crustytoothpaste.net>

On Tue, Jan 11, 2022 at 10:40:47PM +0000, brian m. carlson wrote:

Show 9 quoted lines

> 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.

Show 20 quoted lines

>
> > 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 ?