为什么 git 对标记为二进制的文件发出 CRLF 警告？

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

$ 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

And 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 的情况？

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

See commit 6523728 (28 Jun 2016) by Torsten Bögershausen (tboegi).
^{(Merged by Junio C Hamano -- gitster -- in commit 21bed62, 25 Jul 2016)}

convert: 统一“auto" CRLF 的处理

在这次改变之前，

$ 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 (Q2 2017) makes sure the normalization uses the right commands
See commit 8599974 (12 Apr 2017) by Torsten Bögershausen (tboegi).
^{(Merged by Junio C Hamano -- gitster -- in commit 848d9a9, 24 Apr 2017)}

To 触发重新正常化:

从干净的工作目录：

$ 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（2022 年第 2 季度），eol 属性文档已完成。

See commit 8c591db, commit ab96151 (11 Jan 2022) by brian m. carlson (bk2204).
^{(Merged by Junio C Hamano -- gitster -- in commit 8db2f66, 11 Feb 2022)}

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

^{Signed-off-by: brian m. carlson}

eol 属性的文档指出它是“有效设置文本属性”。

然而，这意味着它强制始终设置文本属性，但自从6523728 (convert：统一，2016-06-28，Git v2.10.0-rc0 --merge列于batch #7) (“转换：统一 CRLF 的“自动”处理”，2016-06-28)。

让我们通过清楚地记录“eol”属性在哪些情况下起作用来避免让用户（以及当前作者在尝试向其他人描述 Git 的行为时）感到困惑。

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

gitattributes现在包含在其man page:

该属性仅在以下情况下有效text属性已设置或未指定，或者如果设置为auto和文件 被检测为文本。

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

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

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

See commit 6a5678f (14 Feb 2022) by brian m. carlson (bk2204).
^{(Merged by Junio C Hamano -- gitster -- in commit 66633f2, 23 Feb 2022)}

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

^{Signed-off-by: brian m. carlson}

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

gitattributes现在包含在其man page:

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

该属性仅在以下情况下有效text属性已设置或未指定，或者如果设置为auto，文件被检测为文本，并且它以 LF 结尾存储在索引中.

请注意，在索引中以 CRLF 行结尾的路径上设置此属性可能会使路径被视为脏路径unless text=auto is set.
再次将路径添加到索引将使索引中的行结尾标准化。

使用 Git 2.40（2023 年第一季度），树内.gitattributes更新以匹配我们建议用户将文件标记为文本的方式。

See commit 1f34e0c (03 Feb 2023) by Philip Oakley (PhilipOakley).
^{(Merged by Junio C Hamano -- gitster -- in commit f7c208c, 15 Feb 2023)}

.gitattributes： 包括text属性为eol属性

^{Signed-off-by: Philip Oakley}

文本文件 eol 结尾的标准建议.gitattributes文件已更新于e28eae3 (gitattributes：文档统一，2016-08-26，Git v2.10.0-rc2 --merge）（gitattributes：记录统一的“自动”处理，2016-08-26）最近的澄清8c591db ("docs：有关 eol 属性的正确文档”，2022-01-11，Git v2.36.0-rc0 --merge列于batch #3），原作者的后续评论这个线程，确认 eol 属性与 text 属性的结合使用。

更新 Git 的.gitattributes文件以反映我们自己的建议。

所以而不是：

/Documentation/**/*.txt eol=lf

您现在拥有：

/Documentation/**/*.txt text eol=lf