为什么在标记为二进制的文件上出现 CRLF 的 git 警告？

Question

我有一个被标记为二进制的文件：

$ cat .gitattributes
dist/* binary
$ git check-attr -a ./dist/app.js
./dist/app.js: binary: set
./dist/app.js: diff: unset
./dist/app.js: merge: unset
./dist/app.js: text: auto

并且git diff 正确地将文件视为二进制文件：

$ git diff
diff --git a/dist/app.js b/dist/app.js
index 9c05798..fbcedd4 100644
Binary files a/dist/app.js and b/dist/app.js differ

但是当我运行git status 时，我收到关于CRLF 转换的警告：

$ git status
warning: CRLF will be replaced by LF in dist/app.js.
The file will have its original line endings in your working directory.
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

        modified:   dist/app.js

发生了什么事？为什么 git 会警告我有关此文件中的 CRLF 的信息？

Answer 1

Git 2.10（2016 年第三季度）应该更加小心二进制中的 crlf。

参见Torsten Bögershausen (tboegi) 的commit 6523728（2016 年 6 月 28 日）。
^{（由 Junio C Hamano -- gitster -- 合并于 commit 21bed62，2016 年 7 月 25 日）}

convert：统一CRLF的“auto”处理

在此更改之前，

$ echo "* text=auto" >.gitattributes
$ echo "* eol=crlf" >>.gitattributes

效果和

一样

$ echo "* text" >.gitattributes
$ git config core.eol crlf

由于“eol”属性的优先级高于“text=auto”，这可能会损坏二进制文件，这不是大多数用户期望发生的情况。

现在让“eol”属性服从“text=auto”

$ echo "* text=auto" >.gitattributes
$ echo "* eol=crlf" >>.gitattributes

行为与

相同

$ echo "* text=auto" >.gitattributes
$ git config core.eol crlf

---

Git 2.13（2017 年第二季度）确保规范化使用正确的命令
请参阅 Torsten Bögershausen (tboegi) 的 commit 8599974（2017 年 4 月 12 日）。
^{（由 Junio C Hamano -- gitster -- 合并于 commit 848d9a9，2017 年 4 月 24 日）}

致trigger a re-normalization：

从一个干净的工作目录：

$ echo "* text=auto" >.gitattributes
$ rm .git/index     # Remove the index to re-scan the working directory
$ git add .
$ git status        # Show files that will be normalized
$ git commit -m "Introduce end-of-line normalization"

---

使用 Git 2.36 (Q2 2022)，eol 属性文档已完成。

见commit 8c591db、commit ab96151（2022 年 1 月 11 日）brian m. carlson (bk2204)。
^{（由 Junio C Hamano -- gitster -- 合并到 commit 8db2f66，2022 年 2 月 11 日）}

docs：关于 eol 属性的正确文档

^{签字人：brian m.卡尔森}

eol 属性的文档说明它“有效地设置了 text 属性”。

但是，这意味着它强制 text 属性始终设置，自从6523728 (convert: unify the , 2016-06-28, Git v2.10.0-rc0 -- merge 列于batch #7) ("convert: 统一CRLF的"自动"处理", 2016-06-28)。

让我们通过清楚地记录“eol”属性在哪些情况下有效来避免混淆用户（以及当前作者试图向他人描述 Git 的行为）。

具体来说，除非文件被显式设置为-text，或者文件被设置为text=auto并且文件被检测为二进制文件，否则该属性始终有效。

gitattributes 现在包含在其man page 中：

这个属性只有在text 属性已设置或未指定，或者如果它设置为 auto 并且文件 被检测为文本。

请注意，在路径上设置此属性 在带有 CRLF 行结尾的索引中可能会使路径成为 被认为是脏的。

再次将路径添加到索引将标准化索引中的行尾。

---

为了进一步澄清，使用 Git 2.36（2022 年第二季度）更新了文档：

参见brian m. carlson (bk2204)commit 6a5678f（2022 年 2 月 14 日）。
^{（由 Junio C Hamano -- gitster -- 合并于 commit 66633f2，2022 年 2 月 23 日）}

doc：澄清 'eol' 和 text=auto 之间的交互

^{签字人：brian m.卡尔森}

eol 仅在索引的内容在 LF 行结尾时才对文本文件生效。
索引中内容以 CRLF 行结尾的路径可能会变脏，除非text=auto。

gitattributes 现在包含在其man page 中：

此属性设置要在 工作目录。

此属性只有在设置或未指定text属性时才有效，或者如果设置为auto，文件被检测为文本，并以LF结尾存储在索引中。

请注意，在索引中以 CRLF 行结尾的路径上设置此属性可能会使路径被视为脏路径除非设置了text=auto。
再次将路径添加到索引将规范化索引中的行尾。