【发布时间】：2019-06-11 14:40:14
【问题描述】：
我正在 Linux 上从https://github.com/winlibs/libjpeg 检查一个第三方项目“libjpeg”（这只是一个例子，实际上我在许多其他项目中也有同样的问题）。我有以下 Git 行尾配置。
我只配置了全局设置（设置为以 LF 行结尾结帐）：
$ git config --system -l | grep core
core.eol=lf
core.autocrlf=false
$ git config --global -l | grep core
core.eol=lf
core.autocrlf=false
没有关于行尾的本地（repo）设置。
我阅读了这篇关于 Git 行尾配置的文章：https://adaptivepatchwork.com/2012/03/01/mind-the-end-of-your-line，我认为我的配置应该为 Linux 上的所有文本文件提供 LF。但是它不起作用。我在我的工作区中得到了 CRLF。例如：
~/gitclonetest/libjpeg$ file libjpeg.map
libjpeg.map: ASCII text, with CRLF line terminators
~/gitclonetest/libjpeg$ cat -v libjpeg.map
LIBJPEG_9.0 {^M
global:^M
*;^M
};^M
有人可以帮助我了解我缺少什么吗？我的目标是在 Linux 主机上克隆所有文本文件（适用于任何项目）时自动将其转换为 LF。
更新：目标是将 Git 配置为使用 LF 在 Linux 主机上签出，即使当时文件是使用 CRLF 存储在存储库中的。
【问题讨论】：
-
可能，在存储库中提交的文件已经有 CRLF 行结尾。如果是这种情况，并且您指示 Git 根本不要弄乱行尾——就像在 Linux 上通常那样——那么 Git 将保留文件存储库副本中的 CRLF 行尾，将该文件解压缩为有用的、可编辑的 Linux 文件时。也就是说，如果您告诉 Git：完全保留此二进制数据，Git 会这样做。二进制数据是文本这一事实并不重要。
-
@torek，我已经更新了我的问题。如果我现在贴的flags是错的，你能告诉我，你建议用哪些flags来实现到LF的转换？在我看来，我尝试了所有可能的组合，但没有一个奏效。
-
我检查了（通过克隆存储库），确实提交的文件中有 CRLF 行结尾。你可以告诉 Git 在转换过程中修改这些文件（因为文件是从索引中提取到工作树的），但是因为你在一个“好”的操作系统（Linux）上，你一般不应该这样做。编写此库的人希望您在 Git 内部保留带有 CRLF 行结尾的已提交文件。
-
@torek，那么我的情况的解决方案是什么？是的，很明显该文件是使用 CRLF 提交的。但是我想在 Linux 上结账时总是获得 LF。我不在乎文件提交了哪些行，我只想让 Git 用我对 Git 说的行来检查它。不应该 core.eol=lf 这样做吗？如果不是，那么应该使用什么设置？
-
在这种情况下，您需要一个带有指令的
.gitattributes文件：text eol=lf用于这些特定文件。但效果会是，在您所做的每一个 new 提交中，存储在 repository 中的文件将仅具有 LF 行结尾，这与提交的人的愿望相反将文件放入以 CRLF 行结尾的存储库中。在这种情况下，让 Git 执行此操作毫无意义：您可以提取所有文件，将它们全部转换一次，然后提交。从本质上讲，您是在声明以前的存储库维护者是错误的。 [继续]
标签： git eol core.autocrlf