GitHub Desktop 报 Filename too long：系统 Git 配置未必被使用

Windows 上通过 GitHub Desktop 克隆仓库，报 Filename too long，而终端 Git 已设置 core.longpaths，甚至能克隆同一个仓库。先确认该设置写到了哪个配置文件，以及 Desktop 是否读取了它，不要马上继续修改注册表。

适用场景是检出阶段无法创建较长路径的文件，尤其是只在终端执行过 git config --system core.longpaths true 的情况。GitHub Desktop 和单独安装的 Git 可能使用不同的系统配置路径；终端配置正确，不足以证明 Desktop 的设置已经生效。

先区分文件名长度与完整路径长度

查看 Desktop 的失败日志，确认错误涉及哪个路径。仓库内文件名不长，放到很深的本地目录后，完整路径仍可能超出某些 Windows 程序的处理范围。先尝试一个短的目标目录，例如 C:\repos 下的新目录，避免在失败的半成品目录里反复重试。

失败目录中若已加入自己的文件或修改，先备份并核对，不要把它当成可直接删除的克隆缓存。缩短目标路径不会改变仓库内容，也不会修复单个文件名超出文件系统限制、非法字符、权限拒绝或网络下载失败。日志出现其他错误时，应按实际失败阶段判断。

Windows 的长路径策略与 Git for Windows 的 core.longpaths 是不同层的设置。操作系统允许长路径，也不保证 Git 的相关选项已开启，更不保证所有编辑器、脚本和文件管理器都支持这些路径。

只改 system，Desktop 可能没有读到

在普通用户终端查看该用户的设置及读取文件：

git config --global --get-all core.longpaths
git config --show-origin --get-all core.longpaths

第一条检查用户级配置；没有输出且命令返回未找到，不应当成已设为 true。第二条展示当前终端 Git 所读配置的来源，可帮助发现设置只存在于某个安装目录的系统文件，或被更具体的配置覆盖。

这两条仍只证明当前终端环境，不能当作 Desktop 内置 Git 的直接检测结果。核对 Desktop 日志和实际使用的 Windows 用户；如果程序以另一个用户运行，全局配置也可能不同。

确认需要在该用户的 Git 环境启用长路径，先保存现有全局配置，再设置：

git config --global core.longpaths true

用户级设置通常可以避免把配置写到某一份独立 Git 安装的 system 文件里。随后在 Desktop 重新克隆到干净的短路径目录，检查失败的文件是否完整检出。不要为了改这个用户设置以管理员身份启动 Desktop，也不要直接改它安装目录中的文件。

已经有可用的本地仓库、且仅希望影响该仓库时，可以考虑仓库级 core.longpaths 配置；但还没有克隆完成的 Desktop 操作，不能指望事后写进另一个仓库的配置控制它。

开关不保证整个工具链支持长路径

Git for Windows 的 core.longpaths 为相应的内置命令开启长路径处理，部分脚本及外部程序仍可能失败。因此，Desktop 克隆成功之后，还需检查构建工具、IDE 和日常文件操作是否能访问那些文件。

用户配置已确认，Desktop 仍报相同错误时，保留版本和具体文件路径，继续检查当前版本是否有相关限制、目标路径是否仍过深，以及配置是否被环境或仓库设置覆盖。不要把一次设置无效解释为必须关闭安全软件，也不要把长路径问题变成反复申请管理员权限。

如果项目的目录结构长期超过常用工具的支持范围，缩短克隆根目录或审慎调整仓库路径通常更容易维护。修改仓库中的路径会影响导入、脚本和 CI，应由项目按正常变更流程验证，不应仅在本地随意重命名后提交。

需要回退时恢复原配置

用户级开关影响该 Windows 用户其他 Git 仓库。此前已有明确值时，恢复原值；此前没有设置时，移除本次新增值：

git config --global --unset core.longpaths

只在确认原来没有该项、且本次只新增一个值时使用这条恢复命令。已有重复项或 include 配置时，应按之前记录的配置文件恢复，不能批量删掉无关设置。关闭开关不会缩短已经检出的路径，现有仓库仍可能需要迁移到更短的本地目录。

完成后以 Desktop 的实际克隆结果验收：目标提交正确，原失败文件存在，后续正常构建和文件操作也能完成。终端单独克隆成功，不能替代这项检查。