虽然我已经使用git了几年,但我的本地git最近一直在制作一条新消息(我假设由于存储库的增长).
当我git push在GitHub上对遥控器进行操作时,我得到以下输出(很自然,大部分):
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 pushes已经正常工作),但我只是好奇这个消息的起源和含义,以及为什么数字与实际的对象数量是如此不同计数/计算.
布莱恩彭德尔顿的评论中有正确的答案:你git push做了一个"薄包".智能协议上的所有提取和推送操作都始终使用精简包,以最大限度地减少网络流量.
任何包文件都使用增量压缩.普通Git包文件仅针对同一包中的其他对象进行增量压缩对象(这些其他对象也可以是增量压缩的,但仅针对同一包中的更多对象)."瘦包"是故意违反此规则的包文件:它将对象与其他位置存储的其他(松散或打包)对象进行三角形压缩.在收到一个瘦包时,Git必须通过"丢失"来修复瘦包,并将其丢弃,或者简单地将其破坏(将薄包爆炸成单个非delta压缩的对象).
假设你的Git和其他一些Git正在协商发送一个千兆字节的数据(无论多少个文件 - 简单来说就是1),但两个Gits发现你们都已经拥有了1GB的文件数据,而新的数据可以表示为:"复制旧数据,a从中间删除字母,然后插入the",或者同样短而简单的东西.取其GIT中是做发送使Δ-压缩对象说"从与散列对象开始ħ,在偏移删除1个字节X,添加3个字节the偏移量X ".这个增量压缩对象占用了大量的CPU时间 - 甚至可能需要整整一秒才算出来,但只需要几十个字节的空间.生成的包文件很小,并在几微秒内通过电线.接收Git通过添加丢失的1GB对象来增加它,并且传输完成.
在这种特殊情况下,completed with 12 local objects意味着瘦包依赖于你Git告诉你已经拥有的Git的12个对象.由于Git的DAG的,你的Git也许能告诉他们的混帐,你通过发送只是这些对象一个哈希ID:如果你有犯Ç,你必须每一棵树和BLOB犯下Ç了,而且,只要你不没有"浅"的存储库 - 你也有每个祖先提交C,并且与这些祖先一起提交的每个树和blob都会提交.
因此,这种压缩是图论的直接结果.这也是为什么,即使对于非常大的项目,初始克隆可能很慢,但大多数git fetch更新往往非常快.此规则的主要例外是当您为Git数据对象提供不能与以前的数据对象进行delta压缩时.这包括已经压缩的二进制文件,例如JPG图像或压缩的tarball.(具有讽刺意味的是,至少从理论上来说,未经压缩的压缩包可以更好地压缩,尽管Git的修改后的xdelta在我过去测试过的几个案例中并没有做得很好.)