为什么文件在新克隆后被视为已修改?git-add何时重新规范化.使用过吗

我遇到了一个文件问题，这些文件在新的git克隆后被视为已修改

我回购中的用例：

以下是.gitattributes的外观：

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

以下是我的测试：

测试1

带有2.txt文件的新repo(LF.txt和CRLF.txt)
- LF.txt:eol=LF(整个文件的行尾为LF)
- CRLF.txt:eol=CRLF(整个文件的行尾为CRLF)
添加、提交、推送
添加.gitattributes(包含上述内容)：git add .gitattributes，提交，推送
repo的新克隆
- LF.txt:eol现在是CRLF(如预期)
- CRLF.txt被视为已修饰，即使它仍然具有作为eol的CRLF

测试2

带有2.txt文件的新repo(LF.txt和CRLF.txt)
- LF.txt:eol=LF
- CRLF.txt:eol=CRLF
添加、提交、推送
添加.gitattributes(具有上述内容)：git add --renormalize .
- CRLF.txt被认为是经过修饰和阶段性的(但没有内容差异，eol仍然是CRLF)
- .gitattributes仍未被追踪
轨道.gitattributes:git add .
提交并推送
repo的新克隆
- LF.txt:eol现在是CRLF(如预期)
- CRLF.txt:eol为CRLF(如开头所示)
- 回购是清白的

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

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

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

因此，git可以查看磁盘上的文件，将其Windows风格(CRLF)的行尾转换为普通形式(Unix风格的LF行尾)，并将结果与存储库中的结果进行比较。

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

测试2：什么是git-add——重整化。真的在做什么？

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

如果存储库中的内容实际上并不是您所声称的，那么git add --renormalize将对此进行更正。

为什么它不同时展示.gitattributes？

重新规范化只影响存储库中已经存在的文件，它将"新的‘清理’过程应用于所有跟踪的文件，以强制将它们再次添加到索引中。"(来自git文档；重点是我的。)

因此，它确实只对现有内容进行了重整。

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

是。

相关内容