为什么 git 显示行尾发生了变化，尽管应该有 none？

Question

我有一个文件签入为 CRLF，它应该是 CRLF，如下所示：git ls-files --eol:

i/crlf  w/crlf  attr/text eol=crlf      src/Project.Tests/ReadTestsV4.cs

但它仍然显示文件更改的差异，据说是这样的（真实文件是 CRLF）：

diff --git a/src/Project.Tests/ReadTestsV4.cs b/src/Project.Tests/ReadTestsV4.cs
index 9f139a6..23d11a5 100644
--- a/src/Project.Tests/ReadTestsV4.cs
+++ b/src/Project.Tests/ReadTestsV4.cs
@@ -1,605 +1,605 @@
-^M
-using Renci.SshNet;^M
-using Xunit;^M
-using Project;^M
-using System.Linq;^M
-using System.Diagnostics.CodeAnalysis;^M
-using Microsoft.Extensions.Logging;^M
...
+
+using Renci.SshNet;
+using Xunit;
+using Project;
+using System.Linq;
+using System.Diagnostics.CodeAnalysis;
+using Microsoft.Extensions.Logging;

此项目的git属性是：

*.json eol=lf
*.cs eol=lf
*.csproj eol=lf
*.scss eol=lf
*.ts eol=lf
*.js eol=lf
*.yml eol=lf
*.md eol=lf
*.xml eol=lf
*.html eol=lf
*.config eol=lf
*.txt eol=lf

*.png binary
*.zip binary

# Except for Testing the SSH Libaray CRLF line endings are required for the tests to succeed
src/Project.Tests/**/*.cs eol=crlf
*.bat eol=crlf

我的个人 git 设置是：

[alias]
    c = commit -m
    aa = add --all
    s = status 
    slog = log -n 10 --date-order --abbrev-commit --graph --pretty=format:"%h|%an|%ar|%s"
    glog = log --graph --pretty=oneline --abbrev-commit --decorate --branches --all
[user]
    name = Daniel Habenicht
[core]
    autocrlf = false
    editor = \"C:\MyPath\bin\code.cmd\" --wait
[commit]
    gpgsign = true
[gpg]
    program = C:\Program Files (x86)\GnuPG\bin\gpg.exe

我已经试过了：

git rm --cached -r .
git reset --hard

但它总是显示这些更改。

备注：

Project 是我缩写的真实项目名称的替代。

Answer 1

这是怎么回事：

提交的文件（无法更改）实际上有 CRLF 结尾。
索引副本，一旦你运行git add，不会有CRLF结尾：它会有 LF-only 个结尾。（它目前有 CRLF 结尾，基于 git ls-files --eol 输出，这是有道理的，因为初始索引副本是通过将提交的副本读入索引来制作的。这使提交的副本的 CRLF 结尾完好无损。但是 eol=crlf 在 .gitattributes 中说当你运行 git add, Git 应该 剥离马车 returns, 所以它会这样做。）
未来的提交将根据索引中（将来）的内容进行：也就是说，如果您运行将放在索引中git add.
因此，如果您运行 git add 和 git commit，现在提交的内容与接下来要提交的内容之间的差异涉及删除所有回车 returns一旦您运行 git add.

git add

基本上，任何时候您更改某些文件的“规范化”过程——Git 将该文件或那些文件从提交的副本转换为工作树副本的方式，反之亦然反之亦然——您可能需要先提交一个新的“转换文件”。这样您就可以使新的规范化生效。然后您可以按照通常的方式进行更改，这些更改将按照新的常态进行规范化。

要制作那些新规范化的副本，考虑使用git add --renormalize，如果你的Git不是太古老（很旧的Git版本缺少 --renormalize 选项，您必须将这样的 Git 欺骗到 re-adding 文件中）。在进行任何其他更改之前执行此操作，并进行一个新的提交，该提交的提交消息会提醒您进行此提交的原因。例如：

renormalize files

We changed the `.gitattributes` setting, so we now need to
renormalize files.  Git will show every line changed in
this commit, and `git blame` will point to this commit; use
Git's facilities for skipping over this commit when using
`git blame` because although every line *is* changed, these
changes are purely white-space housekeeping changes that are
not otherwise noteworthy.

现在您已经进行了这个新的提交，以便 提交的 文件与 新常态 匹配，您可以返回工作通常。如果您稍后正在寻找感兴趣的东西运行 git blame 并发现此提交及其错误消息，它会提醒您查找 git blame 文档并了解如何告诉 git blame 不计算重规范化提交。（请参阅 --ginore-rev 和 --ignore-revs-file 选项。）

为什么 git 显示行尾发生了变化，尽管应该有 none？

Why is git showing line endings change although there should be none?

windows

git

line-endings