Question

我在Ubuntu 14.04上使用Git版本1.9.1。

我在一个带有DOS格式和Unix格式文件的新repo中测试了core.autocrlf行为，并确认git add与autocrlf=true一样，按预期产生警告：LF will be replaced by CRLF in ...消息用于Unix格式文件，并且在autocrlf=false时不会为任一文件生成消息。（在这种情况下我不清楚为什么它决定在回购中使用DOS行结尾而不是Unix行，但我不确定这里的重要性。）

然而，在另一个回购中，尽管有autocrlf=true，它仍然告诉我它将转换一些文件：

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

我无法弄清楚为什么会这样做。我正在寻找问题的解释或如何调试它的线索。

附加说明：

不，回购邮件中没有.gitattributes个文件。但它提出了一个有趣的观点，如果autocrlf设置为false会不会产生影响？
不，我只是仔细检查过，文件在每个0x0d后都有一个0x0a，在每个0x0a之前有一个0x0d。

Answer 1

首先，将core.autocrlf设置为false通常是个好主意：请参阅＆＃34; Handling line ending in GIT＆＃34;。

其次，在要添加的文件的父文件夹中查询时，确保core.autocrlf实际上是假的：

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

检查问题是否仍然存在（2018年6月，Git 2.17.1）

第三，该警告是在commit 21e5ad5 Steffen Prohaska (sprohaska) git shows modified files, but I didn't change anything and git reset did not work中于2008年2月（Git v1.5.5）引入的。

对于意外归类为文本的二进制文件，转换可能会破坏数据。

您可能已检查过文本文件，但忽略了二进制文件。

最后，一个很好的方法来检测，因为受eol设置影响的Git 2.8（2016年3月）文件是使用：

git ls-files --eol

请参阅＆＃34; https://docs.google.com/spreadsheets/d/1ov0Zme0jgLEnvuV1tFH577iNe1TzwmPgf6iOuECPdmc/edit?usp=sharing＆＃34;。

使用autocrlf = false的Git仍然会产生“警告：CRLF将被LF替换”消息

1 个答案: