为何配置gc.pruneExpire=never后git prune --expire=never仍运行耗时很久

为什么设置gc.pruneExpire = never后git gc --auto还是会触发git prune #

gc.pruneExpire = never的作用不是禁止git prune命令运行，而是指定未被引用的对象永远不需要被删除，不会跳过git prune的调用流程。
只要仓库满足git gc --auto的触发条件（比如松散对象数量超过gc.auto阈值、pack文件数量超过gc.autopacklimit阈值），git gc就会按默认流程调用git prune子命令，只是会把你的配置值作为--expire参数传入，也就是你看到的--expire never。

本次git prune耗时50多秒实际在执行什么操作 #

从你提供的GIT_TRACE2_PERF日志可以明确看到，99%的耗时都集中在Checking connectivity（连通性检查）阶段：
git prune不管--expire参数是什么值，都需要先完成以下步骤：

1. 读取仓库所有引用（分支、标签、HEAD、stash等）的指向
2. 递归遍历所有被引用的Git对象，构建完整的对象依赖关系图
3. 对比所有存在的松散对象，筛选出未被任何引用关联、且存在时间超过--expire阈值的对象
   只有最后一步删除操作会受--expire never影响被跳过，前面的连通性检查、对象遍历步骤都会完整执行。
   你日志最后的total_objects:0就是指遍历完成后，没有符合删除条件的对象，所以全程没有执行删除操作，但前面的遍历检查已经走完了大仓库的全量对象，所以耗时很长，这种情况在对象总数百万级以上的大仓库、或者存储在机械硬盘的仓库中非常常见。

解决方法 #

如果想要完全避免这个无意义的耗时，可以选择以下任意一种配置：

• 彻底禁用自动GC：执行git config gc.auto 0，之后git gc --auto会直接退出，不会触发任何子流程
• 禁止GC调用prune：执行git config gc.prune false，GC会运行其他步骤但跳过prune调用
• 禁用自动维护任务：执行git config maintenance.auto false，从上游直接阻断git maintenance run --auto的触发逻辑

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