On Thu, 26 Sep 2013, Nguyễn Thái Ngọc Duy wrote:

> About the "packv4" capability in git protocol. I considered a more
> generic cap "packver=ver[,ver[,ver...]]" that represents all supported
> versions, with the order of preference from the first ver (most preferred)
> to the last (least preferred). But it adds more parsing code
> and frankly I don't think we'll have pack v5 in the next five years.
> So I dropped it.

Agreed.  In fact the receiver should only indicate the highest pack 
version it is ready to accept.  We'll have to support the sending and 
receiving of any previous pack versions forever anyway.

> Multi-base tree support is not part of "packv4" capability. Let's see
> if such support comes before the series is merged to master. If so we
> can drop that line from protocol-capabilities.txt. Otherwise a new
> capability can be added for multi-base trees.

What is that for?  Multi-base trees are not created yet, but the code to 
parse them is already there.  So I don't see the point of having a 
capability in the protocol for this.

> Another capability could be added for sending the actual number of
> objects in a thin pack for more accurate display in index-pack. Low
> priority in my opinion.

That just cannot be communicated during capability exchange.  This 
number is known only after object enumeration.  Hence my suggestion of a 
['T', 'H', 'I', 'N', htonl(<number_of_sent_objects>)] special header 
prepended to the actual pack on the wire.  And that has to be decided 
before formalizing the pack v4 capability.  That makes it a somewhat 
higher priority.

> There's also the pack conversion issue. Suppose the client requests v4
> but, for performance purposes, the server sends v2. Should index-pack
> convert the received pack to v4? My answer is no because there's no
> way we can do it without saving v2 first. And if we have to save v2
> anyway, pack-objects (or repack) will do the conversion better. We can
> adjust git-gc to maybe repack more often when the number of v2 packs
> is over a limit, or just repack v2 packs into one v4 pack.

Yeah... those are questions that certainly can wait.  Only 
experimentation will tell what is best, and that won't be conclusive 
until the core git code learns to parse pack v4 data natively.

I'll try to review your patches soon.


Reply via email to