Nicolas Pitre <nico@xxxxxxxxxxx> 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 stream"). -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html