尽管有core.autocrlf=true，但Git在Windows上仅检出带有LF行结尾的特定文件

Question

我们的git代码库中有一个特定的源文件(java)，它会导致我们出现行结束问题。

我们的开发人员都运行Windows，而我们的构建服务器运行Linux。该文件曾在过去的某个时间使用CRLF签入。我们最近在构建过程中引入了Spotless和google-java-format来加强代码风格，但在构建服务器上运行时失败了。

为了解决这个问题，我在我的Windows机器上将行尾转换为LF并提交了文件。这在我们的构建服务器上工作得很好，但现在每次我们在Windows上签出文件时，它都会以LF行结尾进行校验，并且无法通过Spotless检查。

我的git配置(由git config --list验证)上有core.autocrlf=true。我签出的同一个repo中的每个其他文件在Windows上都是CRLF，并且在repo中被正确地转换回LF。只有一个文件引起了问题。这会影响到我们整个团队。

我再次尝试删除和签出文件，甚至删除我的本地存储库和从头开始克隆远程-在Windows上，一个文件总是作为LF出现。我已经尝试了.gitattributes中的各种设置，比如*.java text eol=lf和运行git add --renormalize，但是这个文件的问题仍然存在。你知道为什么这个特定的文件会有这个问题以及如何修复它吗？

Answer 1

原来，源文件有一些字符串形式的修复消息，包括SOH (Unicode 0x0001)消息分隔符。尽管我相信这是有效的UTF-8，但将它们替换为\u0001转义似乎已经解决了问题。这可能是git的文本/二进制检测中的一个错误，这意味着它总是将它们视为二进制文件，而忽略了core.autocrlf。