Menu
While setting up Git for a project, I've noticed that the line-ending normalization works a bit different on Linux and on Windows.
As I understand the Git documentation on this subject, the behavior on Windows is the correct one. Specifically, when a .gitattributes file is present, it should override the core.autocrlf setting.
The following table shows the results of some experimentation I've done. The two left-most columns shows the .gitattributes file and the core.autocrlf setting. The other columns shows the result of the following git commands:
git rm --cached <file> (force next checkout to perform line normalization handling).git checkout HEAD -- <file> (checkout the file, applying line ending normalization)git ls-files --eol <file> (check the line endings in the working tree)+----------------+---------------+-------------+--------------+--------------+--------------------------+--------------------------+ | .gitattributes | core.autocrlf | Linux 2.7.2 | Linux 2.11.0 | Linux 2.16.2 | Windows 2.12.2.windows.2 | Windows 2.16.1.windows.1 | | | | | | | | | +----------------+---------------+-------------+--------------+--------------+--------------------------+--------------------------+ | None | true | w/crlf | w/crlf | w/crlf | w/crlf | w/crlf | | | | | | | | | +----------------+---------------+-------------+--------------+--------------+--------------------------+--------------------------+ | None | false | w/lf | w/lf | w/lf | w/lf | w/lf | | | | | | | | | +----------------+---------------+-------------+--------------+--------------+--------------------------+--------------------------+ | * text=auto | true | w/crlf | w/crlf | w/crlf | w/crlf | w/crlf | | | | | | | | | +----------------+---------------+-------------+--------------+--------------+--------------------------+--------------------------+ | * text=auto | false | w/lf | w/lf | w/lf | w/crlf | w/crlf | | | | | | | | | +----------------+---------------+-------------+--------------+--------------+--------------------------+--------------------------+ | * text=auto | true | w/crlf | w/crlf | w/crlf | w/crlf | w/crlf | | test text | | | | | | | | | | | | | | | +----------------+---------------+-------------+--------------+--------------+--------------------------+--------------------------+ | * text=auto | false | w/lf | w/lf | w/lf | w/crlf | w/crlf | | test text | | | | | | | | | | | | | | | +----------------+---------------+-------------+--------------+--------------+--------------------------+--------------------------+
As you can see, on Linux, it seems that the core.autocrlfsettings has effect, even when a .gitattributesfile is present.
I'd like some help to determine whether this is actually a bug.
228
The default for core. autocrlf is false, meaning that Git will not adjust the end of line, which could lead to CRLF files ending up in the repository (bad). Therefore, it is generally best to set the above configuration for Linux and Windows to ensure that the repository will only contain files with LF .
The git config core. autocrlf command is used to change how Git handles line endings. It takes a single argument. On macOS, you simply pass input to the configuration. For example: $ git config --global core.autocrlf input # Configure Git to ensure line endings in files you checkout are correct for macOS.
A gitattributes file is a simple text file that gives attributes to pathnames. Each line in gitattributes file is of form: pattern attr1 attr2 ... That is, a pattern followed by an attributes list, separated by whitespaces. Leading and trailing whitespaces are ignored.
autocrlf . This is a similar approach to the attributes mechanism: the idea is that a Windows user will set a Git configuration option core. autocrlf=true and their line endings will be converted to Unix style line endings when they add files to the repository.
It seems the misunderstanding comes from interpreting the text attribute as meaning the same thing as the autocrlf config setting.
From the gitattributes docs (https://git-scm.com/docs/gitattributes):
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 core.autocrlf overrides core.eol
(Emphasis added.)
So if you want to use attributes to control the line ending you get in the work tree, you need to set the eol attribute (not merely the text attributes).
In fact there are a couple attributes and a couple config options involved in how line endings are handled, and there are differences (by design) in the default behavior between Windows and *nix. From the git config docs (https://git-scm.com/docs/git-config):
core.eol
Sets the line ending type to use in the working directory for files that have the text property set when core.autocrlf is false. Alternatives are lf, crlf and native, which uses the platform’s native line ending. The default value is native
So, to answer your question: no, what you've described is not a bug.
172
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
