如何在所有克隆/机器上禁用 Git 行尾(CRLF 到 LF)?
声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow
原文地址: http://stackoverflow.com/questions/9933004/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
How to to disable Git end-of-line (CRLF to LF) across all clones/machines?
提问by Chris
As one can glean fromotherposts, Git's end-of-line normalization has its pros and cons. I have one particular Windows-only project where I think the best thing to do is to is to disable end-of-line normalization altogether. That is, I want to leave all newlines (most of which are CRLF) intact, rather than have git normalize them to LF-only behind the scenes, and I want that change to affect all clones of the repository on all machines. The question is the most effective way to do it.
正如您可以从其他帖子中了解到的那样,Git 的行尾规范化有其优点和缺点。我有一个特定的仅限 Windows 的项目,我认为最好的办法是完全禁用行尾规范化。也就是说,我想保留所有换行符(其中大部分是CRLF)完整无缺,而不是让 git 将它们标准化为LF-only 在幕后,并且我希望该更改影响所有机器上存储库的所有克隆。问题是最有效的方法。
Most discussions of Git end-of-line normalization are in terms of core.autocrlf, and I could accomplish my goal by setting core.autocrlf=false. However, this is a git-config setting, and I believe one has to set that separately on each machine by machine. If true, that seems error prone, especially since the msysgitinstaller guides one into setting core.autocrlf=true.
大多数关于 Git 行尾规范化的讨论都是关于 的core.autocrlf,我可以通过设置core.autocrlf=false. 然而,这是一个 git-config 设置,我相信必须在每台机器上单独设置。如果为真,这似乎很容易出错,尤其是因为msysgit安装程序会引导一个人进入设置core.autocrlf=true.
回答by Chris
The best way to avoid having to set core.autocrlfseparately on each machine seems to be checking a .gitattributesfile into the repository containing the single line
避免core.autocrlf在每台机器上单独设置的最佳方法似乎是将.gitattributes文件检入包含单行的存储库
* -text
Or, if you have an older version of Git then
或者,如果您有旧版本的 Git,那么
* -crlf
This tells Git that, for all paths (thus the *), end-of-line normalization should not be attempted. As far as I can tell, this should not have any other side-effects. In particular, it should not alter how diffs are generated (this has separate attribute diff/-diff) or how merges are handled (this has a separate attribute merge/-merge).
这告诉 Git,对于所有路径(因此*),不应尝试行尾规范化。据我所知,这不应该有任何其他副作用。特别是,它不应改变差异的生成方式(具有单独的属性diff/ -diff)或合并的处理方式(具有单独的属性merge/ -merge)。
For more details, I suggest these resources:
有关更多详细信息,我建议使用以下资源:
- The gitattributes documentation (
git help attributesor an online copy) , which describes in detail both how end-of-line normalization works and the particular effects of different attributes. (Probably most relevant aretext,crlf,diff,merge, andbinary.) - Git mailing list thread Is the "text" attribute meant onlyto specify end-of-line normalization behavior, or does it have broader implications?(Mar 30, 2012), which expands on the meaning of different attributes, and clarifies that
-textdoes not mean simply "this is a binary file".
- gitattributes 文档(
git help attributes或在线副本),其中详细描述了行尾规范化的工作原理以及不同属性的特殊效果。(可能是最相关的是text,crlf,diff,merge,和binary)。 - Git 邮件列表线程“text”属性是否仅用于指定行尾规范化行为,还是具有更广泛的含义?(Mar 30, 2012),它扩展了不同属性的含义,并澄清这
-text不仅仅是“这是一个二进制文件”。

