Subject: Re: [RFC PATCH 1/1] protocol-v2.txt: align delim-pkt spec with usage

From: Junio C Hamano <[email-masked]>
Date: Wed, 27 Oct 2021 14:44:01 -0700

Calvin Wan <[email-masked]> writes:

> move delim-pkt from command-args to command-request

That is something we can read from the patch text.  Can we explain
what it means to the human readers?  Let's read on the patch.

> Signed-off-by: Calvin Wan <[email-masked]>
> Reported-by: Ivan Frade <[email-masked]>

These are reversed, aren't they?  Chronologically what happened?
Ivan reported, you wrote a patch, and then you signed it off before
sending, no?  Please align the order of the events with the order of
the trailer lines.

> ---
>  Documentation/technical/protocol-v2.txt | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/technical/protocol-v2.txt b/Documentation/technical/protocol-v2.txt
> index 21e8258ccf..1e75863680 100644
> --- a/Documentation/technical/protocol-v2.txt
> +++ b/Documentation/technical/protocol-v2.txt
> @@ -125,11 +125,11 @@
>      empty-request = flush-pkt
>      command-request = command
>  		      capability-list
> -		      [command-args]
> +			  delim-pkt
> +		      command-args

Are these meant to be unaligned like this?  In this project, a HT
always jumps to the next multiple-of-8 column.

>  		      flush-pkt
>      command = PKT-LINE("command=" key LF)
> -    command-args = delim-pkt
> -		   *command-specific-arg
> +    command-args = *command-specific-arg

OK, so we used to say, after the capability list, there may be
a command-args, or no command-args.  And a command-args begins
with a delim-pkt followed by zero or more command specific args.

We now say after the capability list, there always is a delim-pkt
and zero or more command specific args will follow.

So, the difference (fix) is that the original production allowed a
command-request that ends with capability list (without a final
delim-pkt), but we require delim-pkt after capability-list, whether
there is any command-specific-args?

If so, perhaps the human-readable rewrite of the proposed log
message would be

    The current protocol EBNF allows command-request to end with the
    capability list, if no command specific arguments follow, but
    the protocol requires that after the capability list, there must
    be a delim-pkt regardless of the number of command speficic
    arguments.  Fix the EBNF to match.

By the way, what are we matching this document to with this change?
Our over-the-wire protocol implementation?  I am asking because it
would mean that we may be retroactigvely changing the rules under
other implementations, making what used to be allowed now invalid.