我有一个可以从Windows和OS X访问的Git存储库，并且我知道已经包含一些带有CRLF行尾的文件。据我所知，有两种解决方法：
设置core.autocrlf到false无处不在，
按照此处的说明（在GitHub帮助页面上显示），将存储库转换为仅包含LF行尾，然后在Windows和OS X上将其设置core.autocrlf为。这样做的问题是，如果存储库中有任何二进制文件，那：trueinput
他们将被破坏。我的存储库可能包含此类文件。
那么，为什么不关闭Git的行尾转换呢？网路上有很多模糊的警告，提示您core.autocrlf关闭电源会导致问题，但很少有特定的警告。到目前为止，我唯一发现的是kdiff3无法处理CRLF结尾（对我来说不是问题），并且某些文本编辑器存在行尾问题（对我来说也不是问题）。
该存储库是我公司内部的，因此我不必担心与具有不同autocrlf设置或行尾要求的人们共享它。
我不知道仅将线端保持原样还有其他问题吗？
设置autocrlf为的唯一特定原因true是：
git status将所有文件显示为modified因为将基于Unix的EOL Git存储库克隆到Windows时自动完成EOL转换（例如，参见问题83）除非你能看到哪些具体的治疗必须应对本土停产，你最好留下autocrlf来false（git config --global core.autocrlf false）。
请注意，此配置将是本地配置（因为该配置未从存储库推送到存储库）
如果要为所有克隆该存储库的用户使用相同的配置，请使用文件中的属性，检查“使用git的最佳CRLF处理策略是什么？ ” 。text.gitattributes
例：
*.vcproj text eol=crlf
*.sh text eol=lf
注意：从git 2.8（2016年3月）开始，合并标记将不再在CRLF文件中引入混合行结尾（LF）。
请参阅“使Git在其“ <<<<<<<< HEAD”合并行上使用CRLF ”
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句