Git with autocrlf=false still produces "warning: CRLF will be replaced by LF" messages

Question

I am using Git version 1.9.1 on Ubuntu 14.04.

I have tested the core.autocrlf behaviour in a fresh repo with a DOS-format and a Unix-format file and confirmed that git add with autocrlf=true does, as expected, produce a warning: LF will be replaced by CRLF in ... message for the Unix-format file, and produces no messages for either file when autocrlf=false. (I'm not clear in this case why it decided to use DOS line endings rather than Unix ones in the repo, but I'm not sure that's important here.)

However, in another repo, despite having autocrlf=true, it keeps telling me that it's going to convert some files:

$ git config core.autocrlf
false
$ git add lib/node_modules/pulp/node_modules/webpack/node_modules/webpack-core/node_modules/source-list-map/test/fixtures/from-to-tests/null-source.input.map
warning: CRLF will be replaced by LF in lib/node_modules/pulp/node_modules/webpack/node_modules/webpack-core/node_modules/source-list-map/test/fixtures/from-to-tests/null-source.input.map.
The file will have its original line endings in your working directory.
$

I can't figure out why it's doing this. I'm looking for either an explanation of the problem or clues on how to debug it.

Additional notes:

• No, there isn't a .gitattributes file in the repo. But it raises an interesting point, should it make a difference if autocrlf is set to false?
• And no, I just checked carefully and the file has a 0x0a after every 0x0d, and a 0x0d before every 0x0a.

Answer 1

First, setting core.autocrlf to false is often a good idea: see "Handling line ending in GIT".

Second, make sure core.autocrlf is actually false when queried in the parent folder of the file to add:

git -C lib/node_modules/[...]/fixtures/from-to-tests/ config core.autocrlf

Check also the problem would still persist today (June 2018, Git 2.17.1)

Third, that warning was introduced in Feb. 2008 (Git v1.5.5) in commit 21e5ad5 by Steffen Prohaska (sprohaska).

for binary files that are accidentally classified as text the conversion can corrupt data.

You might have checked text files, but ignored binary files.

Finally, a good way to detect, since Git 2.8 (March 2016) files affected by eol setting, is to use:

git ls-files --eol

See "git shows modified files, but I didn't change anything and git reset did not work".