在我的.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)?
这两个案例似乎没有任何不同的效果。
在处理.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
以获取更多信息...