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

需要修理的内容：

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

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

现在我在Windows中查看git diff,我已经做了一些更改,我可以看到我的文章显示为文本分隔很好的文本…所有要删除并替换为一条长行,其中段落由^ Ms分隔.

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

差异结果意味着我在Linux中启动了文件(完全可能;我不记得了)并且已经将其保存在Windows中并且所有行结尾都已被替换.

我希望能够在两个操作系统中打开文件,其中的行显示为应有的行,并且具有显示换行符(而不是^ 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来做这件事,但我感到很沮丧.)

很高兴回答问题并提供更多细节.我可能会出错的任何想法？我错过了一步吗？

解决方法:

尝试使用

*.md text eol=native

代替

*.md text

在你的.gitattributes中.

我确实在其中设置了一个带有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的理解是有缺陷的,或者我们有一个bug被提交给git ……

无论如何,正如我所说的那样,在.gitattributes中明确设置eol = native对我来说是个窍门.

标签：git,linux,windows,eol,gitattributes
来源： https://codeday.me/bug/20190708/1406096.html