为什么在新克隆后文件被视为已修改？什么时候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（与开头一样）
  • 回购很干净

其他信息

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

问题

1. 测试1：为什么在新克隆后CRLF.txt被视为已修改？
2. 测试2：git add --renormalize .实际在做什么？为什么还不登台.gitattributes？
3. 在已经具有一定历史记录的存储库中设置.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文档；重点是我的。）

因此，它实际上只能重新标准化现有的 内容。

  

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

是的