虽然我已经使用git几年了，但我的本地git最近一直在制作一条新消息（我假设由于存储库的增长而推测）
当我在GitHub上对我的遥控器进行git push时，我得到以下输出（非常自然，大部分）：
Counting objects: 99, done
Delta compression using up to 4 threads.
Compressing objects: 100% (97/97), done.
Writing objects: 100% (99/99), 10.16 KiB | 0 bytes/s, done.
Total 99 (delta 66), reused 0 (delta 0)
remote: Resolving deltas: 100% (66/66), completed with 12 local objects
我感兴趣的具体部分是completed with n local objects，它最近才开始出现。因为，在大多数情况下，存储库正在以相当好的剪辑（在LoC和提交计数中）增长，我假设此消息与此有关，但我不确定是否那就是这种情况。
我知道这不是一个错误（我的git push已经正常工作），但我只是对此消息的来源和含义感到好奇，以及为什么数字与计算/计算的实际物品数量有很大不同。
答案 0 :(得分：7)
Bryan Pendleton's comment有正确的答案：你的git push制作了“瘦身包”。智能协议上的所有提取和推送操作都会一直使用精简包，以最大限度地减少网络流量。
任何包文件都使用delta compression。普通Git包文件仅针对同一包中的其他对象进行增量压缩对象（这些其他对象也可以是增量压缩的，但仅针对同一包中的更多对象）。 “瘦包”是故意违反此规则的包文件：它将对象与其他位置存储的其他（松散或打包）对象进行三角形压缩。收到一个瘦包后，Git必须通过“丢失”来修复瘦包，并将其丢弃（或者简单地将其破坏（将薄包爆炸成单个非delta压缩的对象）。
假设您的Git和其他一些Git正在协商发送一个千兆字节的数据（在许多文件中 - 为了简单起见，我们只是说1），但是两个Gits发现您已经拥有了一千兆字节的文件数据，并且新数据可以表示为：“复制旧数据，从中间删除字母a，然后插入the代替”，或者同样短而简单的内容。无论哪个Git正在进行发送，都会使delta压缩对象说“从具有hash h 的对象开始，在offset x 处删除1个字节，添加3个字节the在偏移 x “。这个增量压缩对象占用了大量的CPU时间 - 甚至可能需要整整一秒才算出来，但只需要几十个字节的空间。生成的包文件很小，并在几微秒内通过电线。接收Git通过添加丢失的1GB对象来增加它，并且传输完成。
在这种特殊情况下，completed with 12 local objects表示瘦身包依赖于你Git告诉你已经拥有的Git的12个对象。由于Git的DAG，你的Git可以通过发送一个哈希ID告诉他们的Git你有这些对象：如果你提交 C ，你就拥有了每一棵树提交 C 的blob和 - 只要你没有“浅”存储库 - 你也让每个祖先都提交 C ，以及与这些祖先一起提交的每一棵树和blob都会提交。
因此，这种压缩是图论的直接结果。这也是为什么，即使对于非常大的项目，初始克隆可能很慢，但大多数git fetch更新往往非常快。此规则的主要例外是当您为Git数据对象提供不能与以前的数据对象进行delta压缩时。这包括已经压缩的二进制文件，例如JPG图像或压缩的tarball。 （具有讽刺意味的是， un 压缩tarball在理论上至少可以压缩得更好，尽管Git的修改后的xdelta在我过去测试过的几个案例中并没有做得很好。）
答案 1 :(得分：0)
注意：消息本身（completed with %d local objects）不是新消息，而是在commit a984a06, Nov. 2007, Git v1.5.4-rc0中引入的
更薄的包装完成情况的更精细显示
出于美化Git仅显示凡人的输出的精神，这是对progress API的简单扩展，允许在终止进度行时提供最终消息，并将其用于显示所需的对象数量完成一个瘦包，又节省了一行屏幕显示。