On Thu, Sep 26, 2013 at 11:51 AM, Nicolas Pitre <n...@fluxnic.net> wrote:
>> 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.

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

Reply via email to