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