git - 什么是 git 的瘦包？

Question

我没有找到太多关于薄包的信息，手册页的信息对此相当含糊。我知道这与慢速连接有关，但什么是“慢速连接”？

它的优点和缺点是什么？什么时候该用，什么时候不该用？

Answer 1

作为记录，man page (index-pack)状态:

It is possible for git-pack-objects to build "thin" pack, which records objects in deltified form based on objects not included in the pack to reduce network traffic.
Those objects are expected to be present on the receiving end and they must be included in the pack for that pack to be self contained and indexable.

这将完成 git push man page --thin 选项:

Thin transfer spends extra cycles to minimize the number of objects to be sent and meant to be used on slower connection

因此，在这种情况下，“慢速网络”是您希望发送尽可能少的数据量的连接。

在“Git fetch for many files is slow against a high-latency disk”中查看更多信息。

---

在this thread , Jakub Narębski解释更多(在远程端和本地端使用 git gc 的上下文中):

Git does deltification only in packfiles.
But when you push via SSH, git would generate a pack file with commits the other side doesn't have, and those packs are thin packs, so they also have deltas...
but the remote side then adds bases to those thin packs making them standalone.

更准确地说:

On the local side:
git-commit creates loose (compressed, but not deltified) objects. git-gc packs and deltifies.

On the remote side (for smart protocols, i.e. git and ssh):
git creates thin pack, deltified;
on the remote side git either makes pack thick/self contained by adding base objects (object + deltas), or explodes pack into loose object (object).
You need git-gc on remote server to fully deltify on remote side. But transfer is fully deltified.

On the remote side (for dumb protocols, i.e. rsync and http):
git finds required packs and transfers them whole.
So the situation is like on local side, but git might transfer more than really needed because it transfers packs in full.

---

上面的问题与git push --thin的使用(或不使用)有关:你什么时候使用它？
事实证明，如果您想让 git 利用这些薄数据包，您确实需要仔细管理您的二进制对象:

1. Create the new filename by just copying the old (so the old blob is used)
2. commit
3. PUSH
4. copy the real new file
5. commit
6. PUSH.

If you omit the middle PUSH in step 3, neither "git push", nor "git push --thin" can realize that this new file can be "incrementally built" on the remote side (even though git-gc totally squashes it in the pack).

In fact, the way thin packs work is to store delta against a base object which is not included in the pack.
Those objects which are not included but used as delta base are currently only the previous version of a file which is part of the update to be pushed/fetched.
In other words, there must be a previous version under the same name for this to work.
Doing otherwise wouldn't scale if the previous commit had thousands of files to test against.

Those thin packs were designed for different versions of the same file in mind, not different files with almost the same content. The issue is to decide what preferred delta base to add to the list of objects. Currently only objects with the same path as those being modified are considered.