【问题标题】:Git * text=auto in the gitattributes file and line endingsgitattributes 文件中的 Git * text=auto 和行尾
【发布时间】:2015-11-23 13:54:39
【问题描述】:

根据这篇文章: What is the purpose of `text=auto` in `.gitattributes` file? 如果 .gitattributes 文件中有以下内容,则文本文件的行尾将转换为 LF:

* text=auto

我刚刚在本地存储库上测试了这个:

$ git add -A
warning: LF will be replaced by CRLF in [bla]/.gitattributes.
The file will have its original line endings in your working directory.
warning: LF will be replaced by CRLF in [bla]/.gitignore.
The file will have its original line endings in your working directory.
warning: LF will be replaced by CRLF in [bla]/README.md.
The file will have its original line endings in your working directory.
warning: LF will be replaced by CRLF in [bla].csproj.
The file will have its original line endings in your working directory.
warning: LF will be replaced by CRLF in 

但那里说它将转换为 CRLF。在上面的帖子中,它说它将转换为 LF,但在本次测试中并非如此。

看来:

* text=auto

将转换为基于操作系统的行尾类型(Windows 为 CRLF,Linux 为 LF)。但这不是这里所描述的:

https://www.kernel.org/pub/software/scm/git/docs/gitattributes.html

根据下面的 cmets/answers,似乎有这个导致的警告:

* text=auto

在 .gitattributes 文件中:

warning: LF will be replaced by CRLF in [bla]/README.md.
The file will have its original line endings in your working directory.

实际上意味着当您进行检出时(下次您将文件从存储库检出到您的工作目录时)当前具有 LF 结尾的文本文件将是转换为具有 CRLF。

警告确实 NOT 解决了在 check-in 行将具有 LF 结尾的问题,这就是文档在此处所说的:

https://www.kernel.org/pub/software/scm/git/docs/gitattributes.html

设置为字符串值“auto” 当文本设置为“自动”时,路径被标记为自动行尾标准化。如果 Git 确定内容是文本,则在签入时将其行结尾规范化为 LF。

【问题讨论】:

  • 相关的是,但不是我在这里要求的。这里是关于特定警告消息的含义,并将其与公共文档中的描述进行比较。
  • 警告不是由text=auto 引起的,而是text=auto 与您之前设置的其他选项有效交互。另一个问题涵盖了其他选项。

标签: git gitattributes


【解决方案1】:

这条消息有点混乱。

只要 Git 与当前行尾转换设置不同,它就会向您发出警告。此警告不是因为 Git 将 CRLF 放入存储库(它不是) - 此警告是因为 Git 将检出的文件与当前磁盘上的文件不同。

无论出于何种原因,您工作目录中的文件都有 Unix 风格的行尾(或 Unix 和 Windows 风格的混合)。您应该能够使用十六进制编辑器看到这一点。例如,我有一个带有 Unix 风格行尾的文件:

C:\Temp>hexdump /C foo
00000000  68 65 6c 6c 6f 21 0a                              |hello!.|
00000007

如果我将文件添加到我的存储库(使用* text=auto 或core.autocrlf=true):

C:\Temp>git add foo
warning: LF will be replaced by CRLF in foo.
The file will have its original line endings in your working directory.

正如 git 所指出的,我当前工作目录中的文件具有其原始(Unix 样式)行结尾:

C:\Temp>hexdump /C foo
00000000  68 65 6c 6c 6f 21 0a                              |hello!.|
00000007   

但是仓库中的文件也有Unix风格的行尾:

C:\Temp>git ls-files --stage
100644 4effa19f4f75f846c3229b9dbdbad14eff362f32 0       foo

C:\Temp>git cat-file blob 4effa19 | hexdump /C
00000000  68 65 6c 6c 6f 21 0a                              |hello!.|
00000007

但是,如果我让 git 创建文件内容 然后,它将创建一个不同的文件 - 一个带有 CRLF 行结尾的文件,这正是该警告所表明的:

C:\Temp>del foo

C:\Temp>git checkout -f foo

C:\Temp>hexdump -C foo
00000000  68 65 6c 6c 6f 21 0d 0a                           |hello!..|
00000008

因此,此消息只是警告您,该文件的下一次检出将不实际上与您当前磁盘上的内容相匹配。在这种情况下,这可能是无害的,但如果您添加的文件的行尾配置对其匹配至关重要。

【讨论】:

  • 好的,这样警告实际上是在您进行签出时解决的,并且与公共文档中的签入规则无关?看我编辑的帖子。
  • 提交和结帐需要从整体上考虑,您的过滤器和行尾设置适用于两者。这是警告您的适当时间,因为这是您唯一可以采取行动纠正错误的时间。
猜你喜欢
  • 2015-03-24
  • 2014-02-23
  • 1970-01-01
  • 2015-09-07
  • 2018-03-17
  • 1970-01-01
  • 2014-03-16
  • 2015-06-08
  • 1970-01-01
相关资源
最近更新 更多