为何git clone存在不确定性？有时工作区干净有时脏

问题背景 #

我在Windows上使用Git 2.40.1，仅设置了core.autocrlf=true，有时执行git clone会得到脏工作区，但相同条件下偶尔又能得到干净的工作区。我知道提交带CRLF的文本文件、配置.gitattributes强制LF、设置autocrlf=true这些场景会引发问题，但不理解为什么会随机出现这种差异。

我用下面的脚本反复重置仓库并检查状态（比完整克隆更快复现），在我的机器上大约尝试5000次后才会得到干净的仓库；还有一个私有仓库，克隆后工作区干净的概率只有8%：

#!/usr/bin/env bash
set -e

# Continuously reset a repo and check its status

REPO_URL="https://github.com/balakine/crlf.git"
REPO_DIR="crlf"
COUNT_TOTAL=0

# Clone the repository
rm -rf "$REPO_DIR"
git clone --branch master --single-branch --depth=1 "$REPO_URL" "$REPO_DIR"
cd "$REPO_DIR"

until git diff --quiet; do
    ((++COUNT_TOTAL))

    # Reset the repository
    git rm --quiet --cached -r .
    git reset --quiet --hard

    printf "\033[0;32mTotal: %s\033[0m\n" "$COUNT_TOTAL"
done

git status

原因分析 #

这种随机现象的核心是Git行尾转换逻辑与Windows文件系统遍历顺序的交互问题，具体可以拆解为三点：

• 文件遍历顺序的不确定性：Windows NTFS文件系统返回目录文件列表时没有固定顺序，Git扫描工作区文件的顺序会随之变化。而行尾转换的处理依赖文件处理顺序，当顺序改变时，部分文件的转换状态可能出现偏差。
• 行尾转换的缓存机制影响：Git为优化性能会缓存行尾转换的状态，不同的文件处理顺序会导致缓存命中情况不同。如果缓存残留了旧状态，可能导致新检出文件的转换结果与索引不一致。
• 索引与工作区的同步逻辑漏洞：执行git reset --hard或克隆时，Git先将文件检出到工作区并转换行尾，再重新扫描工作区与索引对比。这个过程中如果文件处理顺序异常，可能导致个别文件的CRLF/LF转换不彻底，最终表现为工作区脏。

解决建议 #

• 统一仓库行尾配置：在仓库根目录添加.gitattributes文件，明确指定文本文件的行尾规则（例如* text=auto或* text eol=lf），替代依赖core.autocrlf的全局配置，消除转换逻辑的不确定性。
• 禁用自动行尾转换：设置git config --global core.autocrlf false，手动管理文件行尾格式，避免Git自动转换带来的随机问题。
• 升级Git版本：尝试更新到最新稳定版Git，后续版本可能修复了行尾转换中与文件遍历顺序相关的bug。

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