Git使所有签出文件的行尾CRLF

Ant*_*nin 10 linux windows git macos

我在mac上编程,我真的不明白Git对我文件行的结尾做了什么:

我创建了一个包含Unix格式文件的存储库(LF行尾).

当我克隆我创建的存储库时,我的所有行都是CRLF.它不应该自动检测到我需要LF线端?

我将autoclrf设置为true.

GIT关于autoclrf的文档很难理解:

如果您只想在工作目录中使用CRLF行结尾而不管您正在使用的存储库,则可以设置配置变量"core.autocrlf"而不更改任何属性.

[核心]

   autocrlf = true
Run Code Online (Sandbox Code Playgroud)

这不会强制所有文本文件的规范化,但确保引入存储库的文本文件在添加时将其行结尾标准化为LF,并且已在存储库中标准化的文件保持规范化.

第一句话说"如果你想拥有所有的crlf",当第二句话说git会自动调整行尾.

就我而言,似乎Git将所有内容转换为CRLF,并在我尝试克隆时将其保留.

Jus*_*hur 5

gitattributes手册页的布局很差.在后面的部分中,您将找到:

core.eol该行结束git会使用在你的工作目录标准化文件中的配置变量控制; 默认设置是使用您平台的本机行结尾,或者core.autocrlf设置CRLF .

因此,除非您已指定,否则core.eol无论您使用的是Apple Mac OS X,Microsoft Windows还是Ubuntu Linux,都会以CR + LF字符终止行.

从你的问题:

第一句:"如果你想拥有所有CRLF",当第二句话说,git会自动调整线的末端.

重要的是要注意,当core.autocrlf设置为时,有两个调整方向true:

  • CR + LF将成为存储库/存储库中的 LF .也就是说,提交文件和存储库后端将在文本文件的行末尾有LF.这样可以在提交历史记录中保持一致,如果您的同事的IDE决定将您的LF神奇地转换为CR + LF(谁想要在他们的差异中看到它?),那么差异/比较会更容易.我猜你也会节省几个字节的硬盘空间.
  • LF将成为工作目录中的 CR + LF .在签出的文件系统中,任何新文本文件都会有一行以CR + LF结尾,一旦git触及它.即使文件在第一次创建时以明细LF结尾的行也会发生这种情况.

你要做的第一件事是取消设置core.autocrlf或设置它false.如果您希望签出文本文件以符合用户的OS首选行结尾,无论它们是如何创建的,只需将其添加到.gitattributes:

* text=auto
Run Code Online (Sandbox Code Playgroud)

或者,如果git不擅长猜测你的哪个文件是文本,你可以声明一个特定的扩展来进行这种双向规范化:

*.ext text
Run Code Online (Sandbox Code Playgroud)

(有ext问题的文件扩展名在哪里)