为什么在新克隆后文件被视为已修改？ git 什么时候添加 --renormalize 。用过的？
Why are files seen as modified after fresh clone? When is git add --renormalize . used?
我对在新 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,commit,push
- repo 的新克隆
LF.txt：eol 现在是 CRLF（如预期）CRLF.txt 被视为已修改，即使它仍然具有 CRLF 作为 eol
测试 2
- 带有 2 个 .txt 文件的新存储库（LF.txt 和 CRLF.txt）
LF.txt: eol=LFCRLF.txt: eol=CRLF
- 添加、提交、推送
- 添加
.gitattributes（内容如上）：git add --renormalize .
CRLF.txt 被视为修改和上演（但没有内容差异，eol 仍然是 CRLF）.gitattributes 仍未追踪
- 曲目
.gitattributes：git add .
- 提交并推送
- repo 的新克隆
LF.txt：eol 现在是 CRLF（如预期）CRLF.txt: eol 是 CRLF（和开头一样）- 回购是干净的
附加信息
- OS: Windows 10
- git版本：2.20.1.windows.1
问题
- 测试 1：为什么 CRLF.txt 在新克隆后被视为已修改？
- 测试 2：
git add --renormalize . 实际上在做什么？为什么它不上演 .gitattributes？
- 在已经有一些历史的回购中设置
.gitattributes 时，是否建议 运行 git add --renormalize 以避免在新克隆后修改文件？
Test 1: why is CRLF.txt seen as modified after a fresh clone?
因为你对 git 撒了谎：你告诉 git 你的存储库中 CRLF.txt 的行尾是 Unix 风格 (LF) 行尾，但是您想要 Windows 样式 (CRLF) 行结尾 在您的工作文件夹 中。这就是 text 属性的含义：规范化行结尾，以便它们在存储库中具有 Unix 样式的行结尾。
但是您的第一个步骤是将具有Windows样式行尾的文件添加到存储库中。
因此，git 可以查看磁盘上的文件，将其 Windows 样式 (CRLF) 行结尾转换为正常形式（Unix 样式 LF 行结尾），然后进行比较结果存储库中的内容。
那些内容不匹配。因此，它认为您已经修改了文件。 这 就是您重新规范化文件的原因。
Test 2: what is git add --renormalize . actually doing?
它会更新文件以匹配您在 .gitattributes 中声明的内容。当您添加 .gitattributes 时，您并没有更改磁盘上或存储库中文件的内容。但是您可能（在这种情况下是）改变您对存储库中内容存在方式的声明。
如果存储库中的内容不是实际上您声明的内容，那么git add --renormalize将更正该内容。
Why doesn't it stage .gitattributes also?
重新规范化仅影响存储库中已有的文件，它适用 "the 'clean' process freshly to all tracked files to forcibly add them again to the index."（来自 git 文档；强调我的。）
所以它真的只重新规范化现有的内容。
When setting up .gitattributes in a repo which already has some history, is it recommended to run git add --renormalize in order to avoid modified files after fresh clone?
是的。
我对在新 git 克隆后被视为已修改的文件有疑问。
- 所有文本文件都应具有
eol=LF，除了*.txt文件应具有eol=CRLF。
下面是 .gitattributes 的样子：
* text=auto
*.txt text eol=crlf
*.png binary
*.jpg binary
*.bmp binary
这是我的测试：
- 带有 2 个 .txt 文件的新存储库（LF.txt 和 CRLF.txt）
LF.txt: eol=LF（整个文件的行尾是LF）CRLF.txt: eol=CRLF（整个文件的行尾是CRLF）
- 添加、提交、推送
- 添加
.gitattributes（内容如上）：git add .gitattributes,commit,push - repo 的新克隆
LF.txt：eol 现在是CRLF（如预期）CRLF.txt被视为已修改，即使它仍然具有CRLF作为 eol
- 带有 2 个 .txt 文件的新存储库（LF.txt 和 CRLF.txt）
LF.txt: eol=LFCRLF.txt: eol=CRLF
- 添加、提交、推送
- 添加
.gitattributes（内容如上）：git add --renormalize .CRLF.txt被视为修改和上演（但没有内容差异，eol 仍然是CRLF）.gitattributes仍未追踪
- 曲目
.gitattributes：git add . - 提交并推送
- repo 的新克隆
LF.txt：eol 现在是CRLF（如预期）CRLF.txt: eol 是CRLF（和开头一样）- 回购是干净的
附加信息
- OS: Windows 10
- git版本：2.20.1.windows.1
问题
- 测试 1：为什么 CRLF.txt 在新克隆后被视为已修改？
- 测试 2：
git add --renormalize .实际上在做什么？为什么它不上演.gitattributes？ - 在已经有一些历史的回购中设置
.gitattributes时，是否建议 运行git add --renormalize以避免在新克隆后修改文件？
Test 1: why is CRLF.txt seen as modified after a fresh clone?
因为你对 git 撒了谎：你告诉 git 你的存储库中 CRLF.txt 的行尾是 Unix 风格 (LF) 行尾，但是您想要 Windows 样式 (CRLF) 行结尾 在您的工作文件夹 中。这就是 text 属性的含义：规范化行结尾，以便它们在存储库中具有 Unix 样式的行结尾。
但是您的第一个步骤是将具有Windows样式行尾的文件添加到存储库中。
因此，git 可以查看磁盘上的文件，将其 Windows 样式 (CRLF) 行结尾转换为正常形式（Unix 样式 LF 行结尾），然后进行比较结果存储库中的内容。
那些内容不匹配。因此，它认为您已经修改了文件。 这 就是您重新规范化文件的原因。
Test 2: what is git add --renormalize . actually doing?
它会更新文件以匹配您在 .gitattributes 中声明的内容。当您添加 .gitattributes 时，您并没有更改磁盘上或存储库中文件的内容。但是您可能（在这种情况下是）改变您对存储库中内容存在方式的声明。
如果存储库中的内容不是实际上您声明的内容，那么git add --renormalize将更正该内容。
Why doesn't it stage .gitattributes also?
重新规范化仅影响存储库中已有的文件，它适用 "the 'clean' process freshly to all tracked files to forcibly add them again to the index."（来自 git 文档；强调我的。）
所以它真的只重新规范化现有的内容。
When setting up .gitattributes in a repo which already has some history, is it recommended to run git add --renormalize in order to avoid modified files after fresh clone?
是的。