因此,我决定将 git 存储库中所有带有 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 存储。 最佳答案
经过数小时的尝试(但失败)以找到关于 .gitattributes
格式的良好规范,我决定尝试以下操作(请注意,这不是解决问题的正确方法):
*.bat -text
而且,瞧,批处理文件从
git status
中消失了,这表明文件的语法没有问题,正如我最初假设的那样。虽然我不想将批处理文件视为二进制文件,但这使我得出了我现在认为是正确的结论:在使用
text
属性标记文件时,我误解了 git 的实际作用。它始终在内部存储带有 LF 行结尾的文件,并且仅在结帐时转换为 CRLF。所以我最初的步骤是完全正确的,他们只是产生了让我觉得有问题的输出。这些文件实际上已经改变了;以前它们与 CRLF 一起存储,但现在它们将仅与 LF 行结尾一起存储,这将在结帐时更正。关于git - 为什么 .gitattributes 中没有 eol=crlf,我们在Stack Overflow上找到一个类似的问题:https://stackoverflow.com/questions/35316053/