必须在 clone 前设置 core.longpaths true 并启用 Windows 系统级长路径支持，否则已报错目录需删除重来；Git 2.30+ 与系统注册表/组策略双生效才真正起作用。
直接开 core.longpaths 就能解决，但必须在 clone 前设置，否则已报错的目录无效，删掉重来是唯一办法。
为什么 core.longpaths true 必须提前设
这个配置只影响后续的文件创建行为，不修复已存在的长路径文件。Git 在 git clone 或 git checkout 过程中一旦遇到超长路径，就会中断并留下半成品工作区——此时再补开配置，Git 仍会拒绝覆盖或重建那些路径，因为 Windows 内核已经拦下了操作。
- 运行
git config --global core.longpaths true后，必须新开一个空目录重新git clone - 如果已在报错目录里，
git status可能卡住或显示混乱，别挣扎，直接rm -rf整个目录 - IDE（如 VS Code、IntelliJ）可能缓存了旧 Git 配置，改完要重启编辑器
Windows 系统级限制也要同步打开
仅开 Git 配置不够稳。Git 2.30+ 虽默认调用 Windows 长路径 API，但前提是系统本身允许。否则 core.longpaths true 会静默降级，你根本察觉不到它没生效。
git-staged-commit-message
下载
仅从仓库的暂存文件生成 Git 提交消息。当用户要求 Codex 根据暂存更改、缓存差异、Git 索引或已通过 `git add` 添加的文件来编写、起草、创建或建议提交消息时使用；切勿代表用户执行提交操作。
- 注册表路径：
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem，新建或修改LongPathsEnabled为1 - 组策略（专业版/企业版）：
计算机配置 → 管理模板 → 系统 → 文件系统 → 启用 Win32 长路径 - 改完必须重启，否则 NTFS 驱动层不加载新策略
验证是否真正生效
别只看配置值，要实测。很多开发者输完 git config --get core.longpaths 回显 true 就以为搞定了，结果一 clone 还是报错。
- 先确认系统重启完成，再打开终端
- 进一个空目录，执行
git clone --depth=1（浅克隆更容易触发路径问题） - 若仍报
error: unable to create file ...: Filename too long，说明系统级开关没起作用，不是 Git 配置问题 -
git version应 ≥ 2.30；低于该版本即使开了core.longpaths也可能底层调用失败
最易被忽略的是：Git 的长路径支持和 Windows 的长路径支持是两层开关，缺一不可；且任何一层没生效，错误现象完全一样——你看到的永远只是那句“Filename too long”。
