@@ -72,14 +72,29 @@ interleaved with S-R-Q.
72
72
thin-pack
73
73
---------
74
74
75
- This capability means that the server can send a 'thin' pack, a pack
76
- which does not contain base objects; if those base objects are available
77
- on client side. Client requests 'thin-pack' capability when it
78
- understands how to "thicken" it by adding required delta bases making
79
- it self-contained.
80
-
81
- Client MUST NOT request 'thin-pack' capability if it cannot turn a thin
82
- pack into a self-contained pack.
75
+ A thin pack is one with deltas which reference base objects not
76
+ contained within the pack (but are known to exist at the receiving
77
+ end). This can reduce the network traffic significantly, but it
78
+ requires the receiving end to know how to "thicken" these packs by
79
+ adding the missing bases to the pack.
80
+
81
+ The upload-pack server advertises 'thin-pack' when it can generate
82
+ and send a thin pack. A client requests the 'thin-pack' capability
83
+ when it understands how to "thicken" it, notifying the server that
84
+ it can receive such a pack. A client MUST NOT request the
85
+ 'thin-pack' capability if it cannot turn a thin pack into a
86
+ self-contained pack.
87
+
88
+ Receive-pack, on the other hand, is assumed by default to be able to
89
+ handle thin packs, but can ask the client not to use the feature by
90
+ advertising the 'no-thin' capability. A client MUST NOT send a thin
91
+ pack if the server advertises the 'no-thin' capability.
92
+
93
+ The reasons for this asymmetry are historical. The receive-pack
94
+ program did not exist until after the invention of thin packs, so
95
+ historically the reference implementation of receive-pack always
96
+ understood thin packs. Adding 'no-thin' later allowed receive-pack
97
+ to disable the feature in a backwards-compatible manner.
83
98
84
99
85
100
side-band, side-band-64k
0 commit comments