这种推超大仓库遇到的RPC失败+远程挂断真的头大，我之前推大型项目也踩过类似的坑，除了调http.postBuffer，还有这些方向可以挨个排查：

1. 切换到SSH协议推送 #

HTTP(S)协议在传输超大pack时，很容易触发服务器端的超时或缓冲区限制，而SSH的传输机制对大文件/大pack的兼容性更好。你现在用的是HTTPS地址，改成SSH地址试试：

• 先确保你已经配置好GitHub的SSH密钥（如果没配，先生成并添加到GitHub账户）
• 修改远程地址：

  git remote set-url origin git@github.com:username/repo.git
  

• 再次执行git push origin --force

2. 开启压缩+重新生成本地pack #

你的Git配置里core.compression=0（完全禁用压缩），导致推送的pack达到2.19GiB，这么大的未压缩数据传输时，服务器端很容易处理超时。建议开启压缩并重新整理本地pack：

• 修改压缩配置：

  git config core.compression 6
  

• 重新生成更紧凑的本地pack：

  git repack -a -d -f --depth=250 --window=250
  

• 再尝试推送，此时pack体积会小很多，传输压力也会降低

3. 拆分推送内容，避免一次性推全部 #

如果你的仓库包含大量分支、标签或历史提交，一次性推所有内容很容易触发远程端的限制。可以尝试拆分推送：

• 先单独推送目标分支：

  git push origin --force <你的分支名>
  

• 再单独推送标签（如果需要的话）：

  git push origin --force refs/tags/llvmorg-21.1.5
  

• 或者如果历史提交太多，试试分批次推送（比如先推最近100个提交，再推更早的）：

  git push origin --force HEAD~100:refs/heads/<分支名>
  git push origin --force <分支名>
  

4. 临时禁用Git LFS #

你的配置里启用了LFS，虽然推送日志显示pack-reused 0，但LFS的传输逻辑可能和普通Git对象冲突，导致意外断开。临时禁用LFS试试：

• 卸载LFS的本地钩子：

  git lfs uninstall
  

• 执行推送，推完后再重新启用LFS：

  git lfs install
  

5. 调整其他Git网络/打包配置 #

除了http.postBuffer，还有几个配置可以调整试试：

• 调大http.maxRequestBuffer（设置单次请求的最大缓冲区，和postBuffer配合）：

  git config http.maxRequestBuffer 1073741824
  

• 禁用thin pack推送（默认是thin pack，减少传输体积，但有些服务器对thin pack处理不好）：

  git push origin --force --no-thin
  

• 增大本地pack的大小限制，避免生成过多小pack（你的当前配置是pack.packsizelimit=2g，推送的pack已经超了，调大到4g试试）：

  git config pack.packsizelimit 4g
  

  改完后记得重新执行git repack生成新的pack

6. 检查GitHub仓库的状态和限制 #

• 确认远程仓库没有超限：GitHub免费仓库单文件不能超过100MB，总仓库大小如果超过10GB可能会被限制（LLVM全深度克隆大概几个G，应该没超，但可以检查下）
• 尝试在GitHub仓库的设置页找“Repair repository”选项（如果有的话），修复可能的远程仓库损坏
• 换个时间段推送，有时候GitHub的某个节点会临时出现压力过大的情况

7. 升级Git到最新版本 #

不同系统自带的Git版本可能比较旧，旧版本的HTTP推送逻辑可能有bug，比如对大pack的处理不完善。升级到最新版Git（比如2.40+）后再尝试推送，很多类似的问题升级版本后就解决了

如果以上方法都试过还是不行，建议直接联系GitHub的支持团队，提供你的推送日志，他们可以帮你排查是不是服务器端针对你的仓库有特殊限制或者异常。