重要
重新打包时，请确保使用-F，以便：
将--no-reuse-object选项传递给git-pack-objects
正如the git repack documentation所指出的那样，你发现了。否则你的新压缩级别将不会应用于任何现有对象。
背景
有三个旋钮：

• core.compression设置core.loosecompression和pack.compression的默认值。如果未显式设置，则会将其他两个值保留为其设置或默认设置。
• core.loosecompression设置zlib压缩默认值。如果没有设置，它默认为zlib自己的"最佳速度"值。
• pack.compression设置压缩包的默认值，如果没有设置，默认为zlib自己的"默认压缩"级别（这可能取决于你的zlib，但我认为一般是6;参见Understanding zlib）。

但是在 * pack files * 中，压缩级别与最终的压缩文件大小的相关性可能要小得多，原因是压缩文件的 * format * 是......好吧，这里有一个technical documentation的链接，但是我会将其总结为 * 通常由delta链控制 * 而不是 * 通常由文件内容控制 。
一个 * loose object * 由zlib压缩的Git头文件和原始文件内容组成。这里的压缩（和级别）通常会有和你自己压缩zlib文件一样的效果，因为头文件和一个典型的文件相比非常小，这些字节不会干扰子串的查找。整个对象被压缩，而不考虑任何其他对象。
但是， packed * 对象可以是 * base对象 *，也可以是 * deltified对象 *。如果packed对象是base对象，它的压缩可能类似于loose对象。但是如果packed对象是deltified，它将由二进制指令组成，而不是文本。这些不太可能压缩得很好。
假设增量链的平均长度是20个对象，这意味着每一个基本对象就有19个增量对象，假设压缩效果很好（比如说，缩小到原始大小的35%），并且非常（比如说，原始大小的97%）。进一步假设基本对象的平均大小是64K，而增量对象（包括指令）的平均大小是6.4K，那么将这些数字改进为，比如说，分别为32%和94%-这可能比较现实，但我没有进行任何实际测量-将使我们：

• 原始数据：35%（65536）+19 *（97%（6554））= 22938 + 19 * 6537 = 147141
• 第9级：32%（65536）+19 *（94%（6554））= 20972 + 19 * 6161 = 138031

这并不像我们预期的那么大的收益：松散对象将收缩约8.5%，而打包文件收缩约6.5%。
(The对真实的Git数据做各种打包实验的结果，而不是这些思想实验，会很有趣。更有趣的可能是尝试上面第一个链接中提到的其他压缩算法。

如何设置Git压缩级别？
https://git-scm.com/docs/git-config

git config core.compression -1
# default compression level
# -1 is default.
# 0 means no compression,
# and 1..9 are various speed/size tradeoffs,
# 9 being slowest.

git config core.looseCompression -1
# compression level for objects
# that are not in a pack file.

git config pack.compression -1
# compression level for objects in a pack file.
#
# Note that changing the compression level
# will not automatically recompress all existing objects.
# You can force recompression
# by passing the -F option to git-repack
# example: git repack -a -d -F