我正在使用CRLF处理repo本身中有一些.C和.H文件的repo，而其余的似乎是使用标准LF。因此，＆＃39; auto＆＃39;转换（我认为所有文本文件都是LF）并不会触及它们。这导致这些文件被修改为看起来像CRLF churn。
如果我的理解是正确的，这是因为GIT期望工作树是LF，因为它期望repo文件是LF并且它没有启动它所知道的任何转换，因此CRLF看起来被修改。 / p>
如果所有这些看起来都很合理，那么我的问题是 - 是否有办法配置GIT，以便 在结帐/提交时转换那些CRLF-repo＆＃39; d文件？在这个特定的例子中，它在Mac上，所以我要去：
repo CRLF -> working LF
edit LF-file
checkin, going
working LF -> repo CRLF
修复原始CRLF - ＆gt; LF可能更好，但我不控制回购
答案 0 :(得分：3)
这不是相当正确，但足够接近：这里的问题是Git有什么相当于方向转换。 Git文档没有以这种方式谈论它的转换，但也许它应该。
将Git中存储的文件视为“Git格式”可能会有所帮助：压缩，如果您通过.gitattributes和您的配置定义清理过滤器，清洗。即使您没有定义特定的清理过滤器，如果您设置了CRLF转换，Git也会在此处执行一些清理：存储在存储库中的文件将仅为LF。正如您所说，工作树中的文件应该采用您首选的工作格式：不是Git压缩，使用CRLF结尾如果您选择了它们，并且污迹通过你的涂抹过滤器，如果你设置其中一个（类似于设置一个干净的过滤器）。
这主要适用于Windows用户，其中Windows编辑器和环境对CRLF行结尾有某种偏好。当这一切都正确设置时，工作时使用的文件的工作副本具有Windows所需的CRLF结尾，并且只能通过将它们检出工作副本来使用的文件的提交副本具有LF-只会以Linux喜欢的方式结束。
这些转换实际上是在文件从索引 - Git在提交和工作树之间施加的中间结构 - 工作树或工作树中移动时执行的到索引。 Git从索引中的任何内容进行提交，因此通过从工作树到索引的方式“清理”文件，Git可以提交干净的版本，并且通过在从索引到工作树的路上弄脏文件，Git可以提供Windows喜欢的脏CRLF结尾。
我们可以打开或关闭此类转换。当所有一直关闭 时，Git不会费心检查任何内容，因此索引中的文件纯粹只是压缩版本的工作树中的文件和工作树中的文件纯粹只是索引中任何内容的未压缩版本（直到您自己修改工作树版本）。在这种情况下，您可以将CRLF结尾放入存储库。这似乎是您的特定存储库发生的事情。
在CRLF不会损害可用性（大多数系统）的任何系统上处理此问题的最简单方法就是离开它。下一个最简单的方法是在repo中修复 ，但正如你所说，这需要控制存储库。
如果某个特定文件由于其CRLF结尾而给你带来问题，那么Git中没有任何内容可以将其转换为仅在工作树中的LF，然后在git add结果时返回到CRLF。但是，您可以设置自己的涂抹和清洁过滤器，使其完全相同：将污迹过滤器清理文件（通过将CRLF转换为仅LF），并使用干净的过滤器脏文件（通过将LF-only转换为CRLF）。然后，您可以在特定文件上设置.gitattributes或.git/info/attributes文件，以使用这些过滤器。有关详细信息，请参阅the gitattributes documentation，但实质上是：
badfile1.ext filter=reverse-clean
badfile2.xtn filter=reverse-clean
以及：
[filter "reverse-clean"]
clean = sed -e $'s/\\r*$/\\r/'
smudge = sed -e $'s/\\r$//'
（现在作为Git过滤器驱动程序测试 - 上面假设命令被送到sh -c而你的sh解释$'...';加倍的反斜杠是由于这一事实到配置文件中。）
正如您在下面的评论中所指出的那样，git diff显示了更改行上的回车符，但周围的行没有显示回车，这使得差异看起来有点难看。它确实似乎按预期工作。