使用`.gitattributes`文件修复Git仓库中的行尾

什么需要修复:

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

我从几个不同的计算机编辑文件,一个运行Linux和一个运行Windows的夫妇。

现在在Windows中查看一个git diff ,我可以看到我的文章显示为很好的分隔的文本行…所有即将被删除,并由一个长行代替,其中段由^M秒。

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

diff结果意味着我在Linux中启动了这个文件(完全可能;我不记得了),然后把它保存在Windows中,并且所有的行结尾都被replace了。

我希望能够在两个操作系统之间打开文件,并显示行,并显示换行符(而不是^M占位符),只改变实际内容。

我试过了:

我已经做了一些背景阅读 ,阅读线结束和Git设置的一个很好的概述 ,甚至尝试跟在另一个堆栈溢出问题的命令。

现在,我有一个.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来做到这.gitattributes ,但我感到沮丧。)

乐于回答问题并提供更多细节。 任何想法,我可能会出错? 我错过了一个步骤?

Solutions Collecting From Web of "使用`.gitattributes`文件修复Git仓库中的行尾"

尝试使用

 *.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的默认值是本地的。 所以,我希望使用LF来检查我的文件。 但是,似乎由于某种原因,这只是没有这样做。 所以,我对.gitattributes的理解是有缺陷的,或者我们有一个bug被提交给git …

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