在我的.gitattributes中(案例1):
###############################################################################
# Set default behavior to automatically normalize line endings.
###############################################################################
* text=auto
# Declare files that will always have CRLF line endings on checkout.
*.sln text eol=crlf
我也尝试过(案例2):
###############################################################################
# Set default behavior to automatically normalize line endings.
###############################################################################
#* text=auto
# Declare files that will always have CRLF line endings on checkout.
*.sln text eol=crlf
一般情况是否有效且允许* .sln文件始终使用crlf,或者一般情况是否会覆盖特殊情况(案例1)?
这两种情况似乎没有任何不同的效果。
答案 0 :(得分:1)
处理.gitattributes
时,会考虑与文件匹配的每个模式,后者会覆盖先前的模式。因此,在这种情况下,对于*.sln
,您最终得到属性text eol=crlf
,因为text
会覆盖text=auto
。在"案例2" text=auto
没有开始,所以它没有被覆盖,但最终结果属性集仍然是相同的,这解释了为什么你的两个案例不显示不同行为。
设置text
的结果是:
Set Setting the text attribute on a path enables end-of-line normalization and marks the path as a text
file. End-of-line conversion takes place without guessing the content type.
此外,我阅读它的方式,eol=crlf
有些覆盖text
,并强制执行CR / LF样式行结尾,而无需检查文件实际上是否为文本文件:
eol
This attribute sets a specific line-ending style to be used in the working directory. It enables end-of-line
normalization without any content checks, effectively setting the text attribute.
Set to string value "crlf"
This setting forces git to normalize line endings for this file on checkin and convert them to CRLF
when the file is checked out.
阅读git help attributes
以获取更多信息......