我在薄包装上找不到多少，而且手册页的信息对此非常含糊。我知道它与慢速连接有关，但什么是“慢速连接”？
它的优点和缺点是什么？我什么时候应该使用它，什么时候不应该使用它？
答案 0 :(得分：29)
对于记录，man page (index-pack)州：
git-pack-objects可以构建“瘦”包，根据包中未包含的对象以分层形式记录对象以减少网络流量。
这些对象预计将出现在接收端，并且它们必须包含在该包中，以便自包含和可索引。
这将完成--thin选项的git push man page：
精简传输花费额外的周期来最小化要发送的对象的数量，并且意味着在较慢的连接上使用
因此，在这种情况下，“慢速网络”是您希望尽可能发送最少数据量的连接。
点击“Git fetch for many files is slow against a high-latency disk”了解更多信息。
在this thread中，Jakub Narębski解释了更多（在远程端和本地端使用git gc的上下文中）：
Git在packfiles中仅对进行了。< 但是当你通过SSH推送时，git会生成一个包文件，其中包含另一方没有的提交，而这些包是瘦包，所以它们也有增量...
但是远程端则为这些薄包添加了基础，使它们成为独立的。
更确切地说：
在当地方面：
git-commit创建松散（压缩但未整理）的对象。git-gc包装和整理。在远程端（对于智能协议，即git和ssh）：
git创建瘦包，令人满意;
在远程端git要么通过添加基础对象（对象+增量）来使包厚/自包含，要么将包打包到松散对象（对象）中。
你需要在远程服务器上使用git-gc来完全远程控制。但转移是完全的 deltified。在远程端（对于哑协议，即rsync和http）：
git找到所需的包并将它们全部转移 所以情况就像在本地一样，但是git可能会传输超过真正需要的东西，因为它会完全转移包。
上述问题与git push --thin的使用（或不使用）有关：何时使用或不使用？
事实证明，如果您希望git利用这些瘦数据包，您需要仔细管理二进制对象：
- 只需复制旧文件名（因此使用旧版blob）
即可创建新文件名- 提交
- PUSH
- 复制真正的新文件
- 提交
- PUSH。
如果您在步骤3中省略了中间PUSH，则“
git push”和“git push --thin”都不会 可以意识到这个新文件可以在远程端“逐步构建”（即使git-gc完全压缩它在包中）。事实上，瘦包的工作方式是将delta存储在一个未包含在包中的基础对象中 那些未包含但用作delta base的对象当前只是文件的先前版本，它是要推送/获取的更新的一部分。
换句话说，必须有一个同名的先前版本才能使用。
如果先前的提交有数千个要测试的文件，则不会进行扩展。这些瘦包是为同一文件的不同版本而设计的，而不是具有几乎相同内容的不同文件。问题是确定要添加到对象列表的首选delta基数。目前只考虑与被修改路径具有相同路径的对象。
答案 1 :(得分：3)
你会认为禁用瘦选项会使用push --no-thin吗？ 在1.8.5之前你会错的：
“git push --no-thin”实际上禁用了“瘦包转移”优化。
--no-thin 从755225d, 2006-04-29 push.c开头，“thin”选项默认启用，但可以使用--no-thin关闭。
然后Shawn将默认设置更改为0，以便在a4503a1, 2007-09-09中保存服务器资源。 --no-thin效果很好。
一天后，在9b28851中，Daniel从push.c中提取了一些代码，以创建transport.c。他（可能不小心）将0中的默认值从1翻转为transport_get()。
从那时起，
--no-thin实际上是无操作的，因为git-push仍然期望默认值为false，而transport_set_option()中的thin变量只调用push.c1}}是true（这是不必要的） 在这两种情况下，通过调用--no-thin来更正代码以尊重transport_set_option()。
receive-pack了解--reject-thin-pack-for-testing选项，该选项仅用于测试目的，因此无法更新文档。
答案 2 :(得分：0)
我的理解是，它是在两个存储库之间传输对象的优化。
我认为你只在实现自己的git服务而不使用send和receive pack时才使用它。