启用core.autocrlf时如何重置工作目录行尾？存在行为不对称疑问

为什么会出现这种不对称行为？ #

这不是Git的Bug，是行尾处理的逻辑设计导致的：

• 从core.autocrlf=true切换到false时，工作目录里的文件行尾是之前自动转换的CRLF，而索引中存储的是LF格式。Git检出时检测到两者不一致，就会用索引里的LF覆盖工作目录文件，因此显示更新N个路径。
• 反过来从false切换到true时，工作目录文件的行尾和索引保持一致（都是LF）。Git默认不会主动修改哈希值一致的文件，哪怕配置变更需要将LF转成CRLF——因为它没检测到“内容变化”，所以不会触发行尾转换，自然显示更新0个路径。

启用core.autocrlf后重置行尾的方法 #

操作前请确保工作目录没有未提交的修改，避免内容丢失：

方法1：强制重新检出所有文件 #

git rm --cached -r .
git reset --hard

• git rm --cached -r .会将所有文件从索引中移除，但不会删除本地文件
• git reset --hard会重新从仓库拉取文件，此时Git会按照新的core.autocrlf=true配置，将LF转换为CRLF写入工作目录

方法2：用renormalize触发行尾转换 #

git config core.autocrlf true
git add --renormalize .
git checkout .

• git add --renormalize .会强制Git重新处理所有文件的行尾规则，更新索引记录
• 后续git checkout .会将转换后的行尾格式同步到工作目录

内容的提问来源于stack exchange，提问作者Skurhse Rage