为什么在.gitattributes中没有eol = crlf [英] Why isn’t eol=crlf honored in .gitattributes
问题描述
echo* text = auto>> .gitattributes
rm .git / index#强制Git到
git reset#重新扫描工作目录
git status#显示将被标准化的文件
git add -u
git add .gitattributes
git提交-m引入行结束标准化
我后来意识到这也改变了* .bat文件应该保持CRLF。我用下面的 .gitattributes
文件重新尝试了整个过程:
#默认
* text = auto eol = lf
#仅限Windows文件
* .bat text eol = crlf
这似乎没有改变 git status
的输出,批处理文件仍然标记为已更改即使它们是我的工作副本中的CRLF,并且 .gitattributes
将它们设置为完全相同。看起来git会忽略 *。bat
这一行。 git show --raw
也向我展示了这个文件现在被存储在LF中而不是CRLF中。
经过数小时的努力(和失败)找到 .gitattributes
格式的良好规范,我决定尝试以下内容(请注意,这是不正确的解决方案):
*。bat -text
另外,批处理文件从 git status
中消失,表示没有正如我最初设想的那样,该文件的语法问题。虽然我不希望将批处理文件视为二进制文件,但这导致了我现在认为是正确的结论:
我错误地理解了git实际上做了什么当使用文本
属性标记文件时。它始终在内部存储具有LF行结尾的文件,并且仅在结帐时将其转换为CRLF。所以我最初的步骤是完全正确的,他们只是产生了让我困惑的想法,认为某些事情是错误的。 文件实际上已经改变;以前他们与CRLF存储,但现在他们将存储只有LF行结束,这将在结帐时纠正。
So I decided to convert all files with windows-style line endings in our git repo to have unix-style line endings.
I followed the instructions from 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"
I later realized that this had also changed *.bat files which should have remained CRLF. I tried the whole process again with the following .gitattributes
file:
# Default
* text=auto eol=lf
# Windows-only files
*.bat text eol=crlf
This did not seem to change the output of git status
, the batch files were still marked "changed" even though they were CRLF in my working copy and .gitattributes
set them to exactly that. It seemed like git would simply ignore the line with the *.bat
. git show --raw
also showed me the file was now being stored with LF instead of CRLF.
After hours of trying (and failing) to find a good specification on the format of .gitattributes
I decided to try the following (note that this is NOT the correct fix for the problem):
*.bat -text
And, lo and behold, the batch files disappeared from git status
, indicating that there was no problem with the syntax of the file, as I had initially assumed. While I did not want to have batch files treated as binary, this lead me to what I now believe to be the correct conclusion:
I’d misunderstood what git actually does when marking a file with the text
attribute. It always stores the files with LF line endings internally and only converts to CRLF on checkout. So my initial steps were completely correct, they just produced output that confused me into thinking something was wrong. The files had actually changed; previously they were stored with CRLF but now they would be stored with just LF line endings, which would be corrected during checkout.
这篇关于为什么在.gitattributes中没有eol = crlf的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!