为什么文件在新的克隆后被视为修改过？什么时候加.重命名。使用?

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添加--重命名。真的在做什么？

它更新文件以匹配您在.gitattributes中声明的内容。添加.gitattributes时，您不会更改磁盘上或存储库中文件的内容。但是，您可能正在(在本例中)更改您对存储库中内容的存在方式所做的声明。

如果存储库中的内容实际上不是您所声称的内容，那么git add --renormalize将纠正这一点。

为什么它不也舞台.gitattributes？

重正化只影响存储库中已经存在的文件，它将“干净”流程新应用于所有跟踪文件，以强制将它们再次添加到索引中。(从git文档中；强调我的)

因此，它实际上只是对现有内容进行重命名。

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

是。