如何在所有克隆/机器上禁用 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 msysgit
installer 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.autocrlf
separately on each machine seems to be checking a .gitattributes
file 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 attributes
or 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
-text
does not mean simply "this is a binary file".
- gitattributes 文档(
git help attributes
或在线副本),其中详细描述了行尾规范化的工作原理以及不同属性的特殊效果。(可能是最相关的是text
,crlf
,diff
,merge
,和binary
)。 - Git 邮件列表线程“text”属性是否仅用于指定行尾规范化行为,还是具有更广泛的含义?(Mar 30, 2012),它扩展了不同属性的含义,并澄清这
-text
不仅仅是“这是一个二进制文件”。