Does text=auto in .gitattributes always enforce LF line endings and ignore Git's core.autocrlf and core.eol settings?

Question

This is essentially a follow-up to the question asked here about the difference between * text=auto and * text=auto eol=lf in a .gitattributes config: What is the difference between "* text=auto" and "* text=auto eol=lf"?

I think I understand how Git works, but I'd like confirmation because the docs are confusing.

The docs for the text attribute state:

This attribute enables and controls end-of-line normalization. When a text file is normalized, its line endings are converted to LF in the repository. To control what line ending style is used in the working directory, use the eol attribute for a single file and the core.eol configuration variable for all text files. Note that setting core.autocrlf to true or input overrides core.eol (see the definitions of those options in git-config[1]).

So it sounds like Git enforces LF by default if you use * text=auto, making * text=auto eol=lf redundant.

However, the second bolded part of the quote is what's confusing me: Does Git ever respect core.autocrlf or core.eol? I tested this on a Windows machine using PowerShell and Git 2.16.1:

1. Run git config --global core.autocrlf false and git config --global core.eol crlf. The latter is not what you'd usually want, but it's useful for this experiment to see if Git even picks it up at all.
2. Create a text file using Notepad with multiple lines of content. The file should have CRLF line endings.
3. Initialize a Git repo in the same directory.
4. Add the file to Git's index.
5. Run git ls-files --eol and observe that the file has CRLF in both the index and working tree.
6. Add a .gitattributes file with * text = auto. Commit it.
7. Run git add --renormalize . to renormalize the previously committed file.
8. Run git status. Observe that the file has been staged for commit.
9. After committing the file, run git ls-files --eol to observe that the file now uses LF in the index.

So despite me setting core.eol=crlf and turning off core.autocrlf, Git still enforced LF for line endings.

Question: Are the docs misleading? Will text=auto always enforce LF?

Answer 1

I think I figured it out:

• core.autocrlf and core.eol only impact line endings in the working tree, not in Git's index (which will always use LF when normalization is enabled) or the remote copy of your code. Hence the output of git ls-files --eol.

• The eol attribute in .gitattributes implies text, which means it enforces LF in the index and whatever value you've set for eol in the working directory. Example: eol=crlf implies index = LF and working tree = CRLF.

So the docs are slightly misleading in that text=auto does NOT rely on core.autocrlf or core.eol—it always enforces LF line endings for the index. Line endings in the working tree are left as-is unless you configure core.autocrlf, core.eol, or use the eol attribute.