On 03/02, Junio C Hamano wrote:
> Brandon Williams writes:
>
> > + Capabilities
> > +~~
> > +
> > +There are two different types of capabilities: normal capabilities,
> > +which can be used to to convey information or alter the behavior of a
> > +request, and commands, which are the c
On 03/02, Junio C Hamano wrote:
> Brandon Williams writes:
> > +static int is_command(const char *key, struct protocol_capability
> > **command)
> > +{
> > + const char *out;
> > +
> > + if (skip_prefix(key, "command=", &out)) {
> > + struct protocol_capability *cmd = get_capability
On 03/01, Junio C Hamano wrote:
> Brandon Williams writes:
>
> > Documentation/technical/protocol-v2.txt | 171
>
> Unlike other things in Documentation/technical/, this is not listed
> on TECH_DOCS list in Documentation/Makefile. Shouldn't it be?
Yes it should, I'll fix that.
Brandon Williams writes:
> + /*
> + * Function queried to see if a capability should be advertised.
> + * Optionally a value can be specified by adding it to 'value'.
> + * If a value is added to 'value', the server will advertise this
> + * capability as "=" instead of ""
Brandon Williams writes:
> + Capabilities
> +~~
> +
> +There are two different types of capabilities: normal capabilities,
> +which can be used to to convey information or alter the behavior of a
> +request, and commands, which are the core actions that a client wants to
> +perform (f
Brandon Williams writes:
> Documentation/technical/protocol-v2.txt | 171
Unlike other things in Documentation/technical/, this is not listed
on TECH_DOCS list in Documentation/Makefile. Shouldn't it be?
Introduce git-serve, the base server for protocol version 2.
Protocol version 2 is intended to be a replacement for Git's current
wire protocol. The intention is that it will be a simpler, less
wasteful protocol which can evolve over time.
Protocol version 2 improves upon version 1 by eliminatin
7 matches
Mail list logo
