Re: [PATCH 00/10] pack v4 UI support

From: Nicolas Pitre <nico@fluxnic.net>
Date: Sep 26, 2013, 04:51 UTC
Message-ID: <alpine.LFD.2.03.1309260031290.312@syhkavp.arg>
In-Reply-To: <1380162409-18224-1-git-send-email-pclouds@gmail.com>

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

Show 6 quoted lines

> 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.

Show 7 quoted lines

> 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.

Nicolas