Nicolas Pitre <> writes:

>> > ...  I was 
>> > wondering if some kind of prefix to the pack stream could be inserted 
>> > onto the wire when sending a pack v4.  Something like:
>> >
>> > 'T', 'H', 'I', 'N', <actual_number_of_sent_objects_in_network_order>
>> >
>> > This 8-byte prefix would simply be discarded by index-pack after being 
>> > parsed.
>> >
>> > What do you think?
>> I do not think it is _too_ bad if the meter jumped from 92% to 100%
>> when we finish reading from the other end ;-), as long as we can
>> reliably tell that we read the right thing.
> Sure.  but eventually people will complain about this.  So while we're 
> about to introduce a new pack format anyway, better think of this little 
> cosmetic detail now when it can be included in the pack v4 capability 
> negociation.

Oh, I completely agree on that part.  When we send a self-contained
pack, would we send nothing?  That is, should the receiving end
expect and rely on that the sending end will send a thin pack and
never a fat pack when asked to send a thin pack (and vice versa)?

Also should we make the "even though we have negotiated the protocol
parameters, after enumerating the objects and deciding what the pack
stream would look like, we have a bit more information to tell you"
the sending side gives the receiver extensible?  I am wondering if
that prefix needs something like "end of prefix" marker (or "here
comes N-bytes worth of prefix information" upfront); we probably do
not need it, as the capability exchange will determine what kind of
information will be sent (e.g. "actual objects in the thin pack data
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to