为什么 .gitattributes 中不支持 eol=crlf答案

【问题标题】：Why isn’t eol=crlf honored in .gitattributes为什么 .gitattributes 中不支持 eol=crlf
【发布时间】：2016-02-10 21:08:21
【问题描述】：

所以我决定将我们的 git repo 中所有具有 windows 风格行尾的文件转换为具有 unix 风格的行尾。

我按照http://www.git-scm.com/docs/gitattributes#_end_of_line_conversion的指示：

echo "* text=auto" >>.gitattributes
rm .git/index     # Remove the index to force Git to
git reset         # re-scan the working directory
git status        # Show files that will be normalized
git add -u
git add .gitattributes
git commit -m "Introduce end-of-line normalization"

我后来意识到这也改变了应该保持 CRLF 的 *.bat 文件。我使用以下.gitattributes 文件再次尝试了整个过程：

# Default 
*         text=auto eol=lf

# Windows-only files
*.bat     text eol=crlf

这似乎并没有改变git status 的输出，批处理文件仍然被标记为“已更改”，即使它们在我的工作副本中是 CRLF 并且.gitattributes 将它们设置为完全一样。看起来 git 会简单地忽略带有*.bat 的行。 git show --raw 还向我展示了该文件现在使用 LF 而不是 CRLF 存储。

【问题讨论】：

标签： git

【解决方案1】：

经过数小时的尝试（和失败）找到.gitattributes 格式的良好规范后，我决定尝试以下方法（请注意，这不是解决问题的正确方法）：

*.bat     -text

你瞧，批处理文件从git status 中消失了，这表明文件的语法没有问题，正如我最初假设的那样。虽然我不想将批处理文件视为二进制文件，但这让我得出了我现在认为正确的结论：

我误解了 git 在使用 text 属性标记文件时的实际作用。它始终在内部存储具有 LF 行结尾的文件，并且仅在结帐时转换为 CRLF。所以我最初的步骤是完全正确的，它们只是产生了让我误以为有问题的输出。文件有实际改变了；以前它们以 CRLF 存储，但现在它们将仅以 LF 行结尾存储，这将在结帐时更正。

【讨论】：