git EOL 配置中的混淆答案

【问题标题】：Confusions in git EOL configurationgit EOL 配置中的混淆
【发布时间】：2022-11-10 07:29:33
【问题描述】：

我的文件在CRLF 之后的系统和LF 之后的系统上应该具有一致的行尾。 This github article 解释了如何设置它，this git article 解释了有关 .gitattributes 的更多细节：

退房和入住

这些属性会影响存储在存储库中的内容如何复制到工作树文件 (...)

文本
此属性启用和控制行尾标准化。当一个文本文件被规范化时，它的行尾在存储库中被转换为 LF。 (...)

设置为字符串值“自动”
当 text 设置为“auto”时，路径被标记为自动行尾转换。如果 Git 确定内容是文本，则在签入时将其行尾转换为 LF。使用 CRLF 提交文件后，不会进行任何转换。

我知道git会将text文件的行尾转换为LF，这是normalization的结果check-in(store into the repo)。

问题
When the file has been committed with CRLF, no conversion is done 是什么意思？这是否意味着如果我关注.gitattributes，git 不会将js 文件的行尾转换为LF？（或者也许它会确保他们是CRLF）
*.js text eol=crlf
为什么the first article的例子在.gitattributes中有如下设置？ git 不会像过去那样只处理文件，这与.gitattributes 中的任何模式都不匹配吗？
# Set the default behavior, in case people don't have core.autocrlf set.
* text=auto
上面的设置会不会引导我们定义额外的设置，比如跟随一个，所以 git 不会normalize 这样的文件不应该被修改？（因为* text=auto 会让 git 将每个文件都视为text）
# Denote all files that are truly binary and should not be modified.
*.png binary

【问题讨论】：

标签： git eol end-of-line

【解决方案1】：

实际上，我们对 git eol 处理及其可能的配置方式也有同样的困惑。您可以在这里查看我们的帖子，看看是否有帮助。

git EOL-handling: configuration overview

也欢迎您的反馈！

【讨论】：