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

Question

需要修复的地方:

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

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

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

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

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

我希望能够在两个操作系统上打开文件，并显示应有的行，并有一个显示换行符的 diff 结果(而不是 ^M 占位符)并且仅更改实际内容。

我尝试过的:

我做了一些background reading , 阅读 nice overview行尾和 Git 设置，甚至尝试按照 another Stack Overflow question 中的命令进行操作.

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

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

我试过这个(source):

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

还有这个(source):

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 来完成此操作，但我感到很沮丧。)

很乐意回答问题并提供更多详细信息。我可能会出错的任何想法？我错过了一步吗？

Answer 1

尝试使用

*.md text eol=native

代替

*.md text

在你的 .gitattributes 中。

我确实设置了一个带有 CR-LF 文件的小型测试仓库，并按照您的第一个程序执行规范化:

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

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

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

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