Linux NFS共享的Windows端大型Git仓库git status执行失败问题

问题现象 #

Windows挂载Linux NFS共享存储后，在共享目录的Git仓库执行git status时出现以下报错：

C:\repo_location\repo> git status

Refresh index:100% (10000/10000), done
fatal: bad object HEAD
fatal: 'git status --porcelain=2' failed in submodule patha/a
fatal: 'git status --porcelain=2' failed in submodule pathb/b
fatal: 'git status --porcelain=2' failed in submodule pathc/c

• Linux端直接操作该仓库执行git status正常
• Windows本地非NFS挂载的小型Git仓库可正常使用
• 已尝试重新初始化子模块（git init），问题未解决
• 推测可能与Windows路径长度限制、LF/CRLF换行符问题有关，仓库规模较大

解决方案 #

1. 解除Windows路径长度限制

Windows默认限制路径长度为260字符，NFS共享仓库里的超长路径会导致Git无法访问文件：

• 系统级开启长路径支持：
  1. 运行regedit打开注册表编辑器
  2. 定位到HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem
  3. 将LongPathsEnabled的DWORD值改为1（没有就新建这个键值）
  4. 重启电脑生效
• Git端单独开启长路径支持：
  执行命令：

  git config --global core.longpaths true
  

2. 统一换行符配置

Linux和Windows换行符不兼容，NFS环境下容易引发Git索引异常：

• 设置Git自动转换换行符：

  git config --global core.autocrlf true
  

  这个配置会在Windows拉取代码时把LF转成CRLF，提交时再转回LF，适配两端环境。
• 若已有文件存在换行符问题，重置索引并重新检出（注意：会丢弃未提交修改，先备份或提交）：

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

3. 修复子模块的Git对象异常

报错显示子模块执行git status失败，可能是子模块对象损坏或路径解析错误：

• 逐个修复子模块：
  进入每个报错的子模块目录，重新初始化并拉取：

  cd patha/a
  git init
  git remote add origin <子模块远程仓库地址>
  git fetch
  git checkout <对应分支或提交ID>
  cd ../..
  

  按同样方法处理pathb/b、pathc/c等子模块
• 批量更新子模块：
  执行命令一次性处理所有子模块：

  git submodule foreach --recursive git init
  git submodule foreach --recursive git fetch
  git submodule update --init --recursive
  

4. 调整NFS挂载选项

Windows挂载NFS时的权限或锁机制可能影响Git操作：

• 重新挂载NFS时添加nolock选项，避免文件锁定冲突：
  在Windows命令行执行：

  mount -o nolock \\linux-server-ip\nfs-share Z:
  

• 同时确保Linux端NFS共享目录的权限为Git可读写（比如设置权限为755，属主属组匹配运行Git的用户）

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