为什么新克隆后文件被视为已修改？什么时候 git add --renormalize 。用过的？

Question

我对在新的 git 克隆后被视为已修改的文件有疑问。

我的仓库中的用例：

• 所有文本文件都应该有eol=LF，除了*.txt文件应该有eol=CRLF。
  

.gitattributes 的外观如下：

*       text=auto
*.txt   text  eol=crlf
*.png binary
*.jpg binary
*.bmp binary

这是我的测试：

测试 1

• 带有 2 个 .txt 文件（LF.txt 和 CRLF.txt）的新仓库
  • LF.txt: eol=LF（整个文件的行尾是LF）
  • CRLF.txt: eol=CRLF（整个文件中的行尾是CRLF）
• 添加、提交、推送
• 添加.gitattributes（包含上述内容）：git add .gitattributes，提交，推送
• 回购的新克隆
  • LF.txt：eol 现在是 CRLF（如预期的那样）
  • CRLF.txt 被视为已修改，即使它仍然有 CRLF 作为 eol

测试 2

• 带有 2 个 .txt 文件（LF.txt 和 CRLF.txt）的新仓库
  • LF.txt: eol=LF
  • CRLF.txt: eol=CRLF
• 添加、提交、推送
• 添加.gitattributes（内容如上）：git add --renormalize .
  • CRLF.txt 被视为已修改和暂存（但没有内容差异，eol 仍为 CRLF）
  • .gitattributes 仍未被追踪
• 跟踪.gitattributes:git add .
• 提交并推送
• 回购的新克隆
  • LF.txt：eol 现在是 CRLF（如预期的那样）
  • CRLF.txt: eol 是CRLF（和开头一样）
  • repo 是干净的

附加信息

• 操作系统：Windows 10
• git版本：2.20.1.windows.1

问题

1. 测试 1：为什么 CRLF.txt 在新克隆后被视为已修改？
2. 测试 2：git add --renormalize . 实际上在做什么？为什么.gitattributes 也不上台？
3. 在已经有一些历史记录的 repo 中设置 .gitattributes 时，是否建议运行 git add --renormalize 以避免在新克隆后修改文件？

Answer 1

测试 1：为什么 CRLF.txt 在新克隆后被视为已修改？

因为你对 git 撒了谎：你告诉 git 你的存储库中 CRLF.txt 的行尾是 Unix 风格 (LF) 的行尾，但你想要 Windows 风格 (CRLF) 的行尾 在您的工作文件夹中。这就是text 属性的含义：规范化行尾，以便它们在存储库中具有 Unix 风格的行尾。

但您的第一步是将带有 Windows 样式行结尾的文件添加到存储库中。

因此，git 可以查看磁盘上的文件，将其 Windows 样式 (CRLF) 行结尾转换为正常形式（Unix 样式 LF 行结尾），并将结果与​​存储库中的内容进行比较。

这些内容不匹配。因此，它认为您已经修改了文件。 那就是你重新规范化文件的原因。

测试 2：什么是 git add --renormalize 。实际在做什么？

它会更新文件以匹配您在 .gitattributes 中声明的内容。添加.gitattributes 时，不会更改磁盘或存储库中文件的内容。但是您可能会（在这种情况下正在）更改您对存储库中内容存在方式的声明。

如果存储库中的内容不是实际上您声明的内容，那么git add --renormalize 会更正。

为什么它不暂存 .gitattributes 呢？

重新规范化只影响已经在存储库中的文件，它会“对所有跟踪的文件重新应用'清理'过程，以强制将它们再次添加到索引中。” （来自 git 文档；强调我的。）

所以它真的只是重新规范现有内容。

在已经有一些历史记录的 repo 中设置 .gitattributes 时，是否建议运行 git add --renormalize 以避免在新克隆后修改文件？

是的。