时间戳

首页 > 解决方案 > Git REPO CRLF 与本地行结束

git - Git REPO CRLF 与本地行结束

问题描述

我正在使用一个使用 CRLF在 repo 本身中有一些 .C 和 .H 文件的 repo，而其余的似乎使用标准 LF。因此，“自动”转换（我认为所有文本文件都是 LF）不会触及它们。这会导致这些文件被修改，看起来像是 CRLF 流失。

如果我的理解是正确的，这是因为 GIT 期望工作树是 LF，因为它期望 repo 文件是 LF 并且它没有启动它知道的任何转换，因此 CRLF 看起来已修改。

如果所有这些看起来都不错，那么我的问题是 -有没有办法配置 GIT 以便在结帐/提交那些 CRLF 回购文件时进行转换？ 在这个特定的例子中，它在 Mac 上，所以我会去：

repo CRLF -> working LF
edit LF-file
checkin, going
working LF -> repo CRLF

修复原始的 CRLF -> LF 可能更好，但我不控制 repo

标签： git

解决方案

这不太对，但足够接近：这里的问题是 Git 有什么相当于定向转换。Git 文档没有以这种方式谈论它的转换，但也许应该这样。

将存储在 Git 中的文件视为“Git 格式”可能会有所帮助：压缩，如果您通过和您的配置定义一个干净的过滤器，则为 clean 。即使您没有定义特定的清理过滤器，如果您设置了 CRLF 转换，Git 也会在此处执行一些清理：存储在存储库中的文件将是 LF-only。正如您几乎所说的那样，您的工作树中的文件应该是您首选的工作格式：不是 Git 压缩的，如果您选择了它们，则使用 CRLF 结尾，如果您设置其中之一，则通过您的涂抹过滤器涂抹（类似设置一个干净的过滤器）。.gitattributes

这实际上主要针对 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-only），并让清洁过滤器弄脏文件（通过将 LF-only 变为CRLF)。然后，您可以设置一个.gitattributes或.git/info/attributes文件以对特定文件使用这些过滤器。有关更多详细信息，请参阅gitattributes 文档，但本质上是：

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正如您在下面的评论中指出的那样，在更改的行上显示回车有一点点烦恼，但在周围的行上却没有，这使得差异看起来有点难看。不过，它似乎确实可以按预期工作。

推荐阅读