Re: [RFC PATCH 1/4] Document the HTTP transport protocol

[Sverre Rabbelier <srabbelier@gmail.com>]

Heya,

I had some spare time, I hope these comments from someone that is not
too familiar with the protocol are helpful :).

On Fri, Oct 9, 2009 at 07:22, Shawn O. Pearce <spearce@spearce.org> wrote:
> +Compatible clients must expand
> +'$GIT_URL/info/refs' as 'foo/info/refs' and not 'foo//info/refs'.

Does this not need s/must/MUST/

> +       S: ....# service=git-upload-pack
> +       S: ....95dcfa3633004da0049d3d0fa03f80589cbcaf31 refs/heads/maint\0 multi_ack
> +       S: ....d049f6c27a2244e12041955e262a404c7faba355 refs/heads/master
> +       S: ....2cb58b79488a98d2721cea644875a8dd0026b115 refs/tags/v1.0
> +       S: ....a3c2e2402b99163d1d59756e5f207ae21cccba4c refs/tags/v1.0^{}

Shouldn't this contain HEAD as the first ref?

> +       ref_list       = empty_list | populated_list
> +
> +       empty_list     = PKT-LINE(id SP "capabilities^{}" NUL cap_list LF)
> +
> +       non_empty_list = PKT-LINE(id SP name NUL cap_list LF)
> +                        *ref_record

Does this need a s/non_empty_list/populated_list/ ?

> +       cap_list      = *(SP capability) SP

You never define capability.

> + (c) Send one $GIT_URL/git-upload-pack request:

I don't think you documented what $GIT_URL/git-upload-pack means.

> +     If the client has sent 256 HAVE commits and has not yet
> +     received one of those back from S_COMMON, or the client has
> +     emptied C_PENDING it should include a "done" command to let
> +     the server know it won't proceed:
> +
> +       C: 0009done

This should probably move down to after you define what S_COMMON is in
the first place.


> +     Here a "closed set of objects" is defined to have at least
> +     one path from every WANT to at least one COMMON object.

A 'path from' is perhaps a bit unclear.

-- 
Cheers,

Sverre Rabbelier