在我的一个git仓库中，我添加了以下.gitattribute文件来规范LF/CRLF字符：
*.bat text eol=crlf
*.cmd text eol=crlf
*.java text eol=lf
*.scala text eol=lf
*.xml text eol=lf
*.py text eol=lf
*.R text eol=lf
# mimicking apache spark为了测试它的效果，我手动将一个bat文件的行分隔符从CRLF改为LF，不幸的是，当在git中提交和推送这个更改时，它被接受了，尽管明显违反了新的.gitattribute：
https://github.com/tek/splain/commit/9344551a1b61f0bf725cc2d9b8aecdced1e71c8b#diff-33fbd7a182c496726227993443a3cfea58670618db831c51c273dcd8962c861a
这怎么可能？这是git中的bug吗？
1条答案
按热度按时间o0lyfsai1#
这是Git故意的。当将文件保存到索引中时，它本身永远不会将行尾转换为
CRLF。一旦Git被告知某个文件扩展名与text相关联，当你提交一些扩展名为LF的文件时，它会利用一切机会将行尾转换为LF。这可以解释为git最初是为使用
LF的Unix开发的。对于git来说，在行结束时以统一的方式在内部处理文本也是一个一致性问题。这通常不是一个问题，因为在存储库中使用任何代码都应该从正确的
git clone开始，它根据.gitattributes执行转换，以便在工作目录中正确指定行结束。但在某些特殊情况下，你真的需要让git将行结束保存为
CRLF，你可以看看this answer。