Re: [PATCH] protocol upload-pack-v2

From: Duy Nguyen <pclouds@gmail.com>
Date: Mar 6, 2015, 23:55 UTC
Message-ID: <CACsJy8ARDgjBLxYmfyrVcCb5WMnG=w6Ro_j+vVe=Sk6pEfR=Cw@mail.gmail.com>
In-Reply-To: <1425685087-21633-1-git-send-email-sbeller@google.com>

I'm still wondering if we should reserve more from the packet length. We have used length 0000 for pkt-flush. Shawn pointed out that we still have 0001, 0002 and 0003 but we may use some of them to avoid abuse of pkt-flush in some cases. Perhaps we could limit packet length to 0xfff0, so we have 0xfff1-0xffff to assign special meanings in future, if we have to.

On Sat, Mar 7, 2015 at 6:38 AM, Stefan Beller <sbeller@google.com> wrote:

Show 23 quoted lines

> +In version 2, when the client initially connects, the server
> +immediately sends its capabilities to the client. Then the client must
> +send the list of server capabilities it wants to use to the server.
> +
> +   S: 00XXcapabilities 4\n
> +   S: 00XXcap:lang\n
> +   S: 00XXcap:thin-pack\n
> +   S: 00XXcap:ofs-delta\n
> +   S: 00XXagent:agent=git/2:3.4.5+custom-739-gb850f98\n
> +
> +   C: 00XXcapabilities 3
> +   C: 00XXcap:thin-pack\n
> +   C: 00XXcap:ofs-delta\n
> +   C: 00XXcap:lang=en\n
> +   C: 00XXagent:agent=git/custom_string\n
> +
> +----
> +  cap              =  PKT-LINE("capabilities" SP size LF list)
> +  size             =  *DIGIT
> +  capability-list  =  *(capability) [agent LF]
> +  capability       =  "cap:" keyvaluepair LF
> +  agent            =  keyvaluepair LF
> +  keyvaluepair     =  1*(LC_ALPHA / DIGIT / "-" / "_" / "=")

If we send one cap per pkt-line, cap can contain spaces. The question is, should we allow them?

Ending cap lines with LF seems redudant because we already know the line length.

Show 9 quoted lines

> +  LC_ALPHA         =  %x61-7A
> +----
> +
> +The client MUST ignore any data before the pkt-line starting with "capabilities"
> +for future easy of extension.
> +
> +The server MUST advertise "size" as the decimal number of lines following
> +the "capabilities" line. This includes lines starting "cap:" and "agent:" for now.
> +The client MUST ignore lines which start with an unknown pattern.

I think the common pattern in our protocol is to end these with a pkt-flush, instead of send the number of items upfront. If we do that we don't have to specify "cap:" or "agent:" either. All pkt-lines until pkt-flush at the beginning of v2 are cap lines. And agent is just another "capability".

-- 
Duy