Re: [PATCH v2 15/16] index-pack: use nr_objects_final as sha1_table size

Nicolas Pitre [off-list ref] writes:

quoted

quoted

...  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
stream").

On Mon, 9 Sep 2013, Junio C Hamano wrote:

Nicolas Pitre [off-list ref] writes:

quoted

quoted

quoted

...  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
stream").

Do we know the actual number of objects to send during the capability 
negociation?  I don't think so as this is known only after the 
"compressing objects" phase, and that already depends on the capability 
negociation before it can start.


Nicolas