使用`.gitattributes`文件修复Git仓库中的行尾 [英] Fixing the line-endings in a Git repository using the `.gitattributes` file
问题描述
需要修改的是什么：
我有一个包含单个 .md 文件的存储库，其中包含一篇文章我写信。
我从几台不同的计算机上编辑文件，一台运行Linux，另一台运行Windows。
在Windows中查看 git diff 现在我已经做了一些修改，我可以看到我的文章显示为很好的分隔的文本行......所有关于删除并由一个长行代替，其中段落由 ^ M s分隔。
我知道 ^ M 引用Windows的CLRF行尾。
diff 结果意味着我在Linux中启动了该文件（完全可能;我不记得），并且已经将它保存在Windows中，并且所有行结束都被替换了。
我希望能够在两个操作系统之间打开文件，并显示它们应该显示的行，并具有显示lin的 diff 结果e break（而不是 ^ M 占位符），只是改变了实际内容。
我试过了：
我已经完成了一些背景阅读，阅读良好的概述另一个堆栈溢出问题。
现在我有一个 .gitattributes 在我已经提交到存储库本身的存储库的顶级文件中。它包含两行：
＃这些文件是文本并且应该被标准化（将Windows的CLRF转换为LF）
* .md text
我试过这个（ source ）：
git rm --cached -r。
git reset --hard
git add。
git commit -m标准化行结束符
而这（source ）：
git rm --cached -r。
git config core.autocrlf输入
git diff --cached --name-only -z | xargs -0 git add
git commit -m修复crlf问题
在第二行情况下，最后一条命令告诉我没有什么要提交的。 （我也不喜欢改变 core.autoclrf 的想法，因为我试图纯粹通过 .gitattributes ，但我感到沮丧。）
很高兴回答问题并提供更多详细信息。任何想法，我可能会出错？我是否错过了一步？
尝试使用
*。md text eol = native
而不是
*。md text
我没有在其中设置一个带有CR-LF文件的小测试回放，并按照第一个过程执行规范化：
p> git rm --cached -r。
git reset --hard
git add。
git commit -m标准化行结束符
签入时正确标准化的文件。
但奇怪的是，它在检出时仍然保留了CR-LF，即使我在OSX上也是如此。
假设core.eol的默认值是当地人。所以，我希望git使用LF来检查我的文件。但似乎由于某种原因，这只是没有这样做。
所以，我对.gitattributes的理解是有缺陷的，或者我们有一个bug被提交给git ...
在任何情况下，显式设置eol =正如我所说的，.gitattributes中的本地代码对我来说是个诀窍。
What needs fixing:
I have a repository containing a single .md file, which contains an essay I am writing.
I edit the file from a few different computers, one running Linux and a couple running Windows.
Looking at a git diff in Windows now where I have made some changes, I can see my essay showing as nicely separated lines of text ... all about to be removed and replaced by one long line where what were paragraphs are separated by ^Ms.
I'm aware that ^M refers to Windows' CLRF line endings.
The diff result implies that I started the file in Linux (entirely possible; I don't remember) and have since saved it in Windows and that all the line endings have been replaced.
I'd like to be able to open files across both OSs with lines displaying as they should, and have a diff result that shows line breaks (rather than ^M placeholders) and only changes to the actual content.
What I've tried:
I have done some background reading, read a nice overview of line-endings and Git settings, and even tried following the commands in another Stack Overflow question.
As it stands I have one .gitattributes file at the top-level of repository which I've committed to the repository itself. It contains just two lines:
# These files are text and should be normalised (convert Windows' CLRF to LF)
*.md text
I've tried this (source):
git rm --cached -r .
git reset --hard
git add .
git commit -m "Normalize line endings"
And this (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"
In the second case, the last command tells me there is nothing to commit. (I also don't like the idea of changing the core.autoclrf since I'm trying to do this purely through .gitattributes, but I'm getting frustrated.)
Happy to answer questions and provide more details. Any ideas where I could be going wrong? Am I missing a step?
Try just using
*.md text eol=native
instead of
*.md text
in your .gitattributes.
I did set up a small test repo with a CR-LF file in it and followed your first procedure to perform normalization:
git rm --cached -r .
git reset --hard
git add .
git commit -m "Normalize line endings"
That correctly normalized file on check-in. But, weirdly, it still maintained CR-LF when checking-out, even if I am on OSX.
Supposedly, default value for core.eol is native. So, I expected git to checkout my files using just LF. But it seems that for some reason, it's just not doing that. So, my understanding of .gitattributes is flawed, or we have a bug to be filed to git...
In any case, explicitly setting eol=native in .gitattributes did the trick for me, as I said.
这篇关于使用`.gitattributes`文件修复Git仓库中的行尾的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
