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

From: Duy Nguyen <pclouds@gmail.com>
Date: Sep 26, 2013, 05:09 UTC
Message-ID: <CACsJy8De9mMvSpnzHuq+XG+Pfi5QD1fY44uHT8hNQZN6sU-hgg@mail.gmail.com>
In-Reply-To: <alpine.LFD.2.03.1309260031290.312@syhkavp.arg>

On Thu, Sep 26, 2013 at 11:51 AM, Nicolas Pitre <nico@fluxnic.net> wrote:

Show 8 quoted lines

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

pv4_get_tree() can. index-pack cannot.

Show 10 quoted lines

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

The capability is to let the server know the client understands ['T', 'H', 'I', 'N' ..]. The server can choose not to send it later, but that's ok. Hence the new capability. I'm somewhat reluctant to do it because of peeking code in fetch-pack and receive-pack and some refactoring may be needed first. But I could certainly put it on higher priority.

-- 
Duy