linux - 使用 `.gitattributes` 文件修复 Git 存储库中的行尾

Question

我有一个包含单个.md文件的存储库，其中包含我正在写的一篇文章。

我从几台不同的计算机编辑文件，一台运行 Linux，另一台运行 Windows。

现在在 Windows 中查看git diff我已经进行了一些更改的 a ，我可以看到我的文章显示为很好地分隔的文本行......所有即将被删除并被一个长行替换，其中段落由^Ms 分隔。

我知道这^M指的是 Windows 的 CLRF 行尾。

结果diff表明我在 Linux 中启动了该文件（完全有可能；我不记得了），然后将其保存在 Windows 中，并且所有行尾都已被替换。

我希望能够在两个操作系统中打开文件，并按应有的diff方式显示行，并获得显示换行符（而不是^M占位符）并且仅更改实际内容的结果。

我已经完成了一些背景阅读，阅读了关于行尾和 Git 设置的精彩概述，甚至尝试按照另一个 Stack Overflow 问题中的命令进行操作。

.gitattributes就目前而言，我在存储库的顶层有一个文件，我已将其提交给存储库本身。它只包含两行：

# These files are text and should be normalised (convert Windows' CLRF to LF)
*.md text

我试过这个（来源）：

git rm --cached -r .
git reset --hard
git add .
git commit -m "Normalize line endings"

而这个（来源）：

git rm --cached -r .
git config core.autocrlf input
git diff --cached --name-only -z | xargs -0 git add
git commit -m "Fixed crlf issue"

在第二种情况下，最后一个命令告诉我没有什么可以提交的。（我也不喜欢改变的想法，core.autoclrf因为我试图纯粹通过来做到这一点.gitattributes，但我很沮丧。）

很高兴回答问题并提供更多详细信息。有什么想法我可能会出错吗？我错过了一步吗？

score 1 · Accepted Answer

尝试使用

*.md text eol=native

代替

*.md text

在你的 .git 属性中。

我确实设置了一个包含 CR-LF 文件的小型测试存储库，并按照您的第一个过程执行规范化：

git rm --cached -r .
git reset --hard
git add .
git commit -m "Normalize line endings"

签入时正确规范化的文件。但是，奇怪的是，即使我在 OSX 上，结帐时它仍然保持 CR-LF。

据说，core.eol 的默认值是原生的。所以，我希望 git 只使用 LF 来检查我的文件。但似乎出于某种原因，它只是没有这样做。所以，我对 .gitattributes 的理解是有缺陷的，或者我们有一个错误要提交给 git ......

无论如何，正如我所说，在 .gitattributes 中明确设置 eol=native 对我有用。

1 回答 1