Re: [PATCH 07/10] receive-pack: request for packv4 if it's the preferred version

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Nguyễn Thái Ngọc Duy  <pclouds@xxxxxxxxx> writes:

> This is the only plumbing command that is controlled by
> core.preferredPackVersion so far.
>
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@xxxxxxxxx>
> ---
>  Documentation/technical/protocol-capabilities.txt | 4 ++++
>  builtin/receive-pack.c                            | 3 ++-
>  2 files changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/technical/protocol-capabilities.txt b/Documentation/technical/protocol-capabilities.txt
> index be09792..32153cd 100644
> --- a/Documentation/technical/protocol-capabilities.txt
> +++ b/Documentation/technical/protocol-capabilities.txt
> @@ -226,4 +226,8 @@ this capability, the server may send a pack version 4. The server can
>  choose to send pack version 2 even if the client accepts this
>  capability.
>  
> +The receive-pack server advertises this capability if it wants to
> +receive the pack in format version 4 and the client should send in
> +this format.

Technically, "if it can and if it wants to receive" is more correct,
as a v4 capable receiving end can choose to pretend it does not
understand v4 by not sending this capability. Also a v4 incapable
receiver would not advertise it even if it _wants_ to receive.  So
in practice, we see this header only from a receiver that wants to
receive v4, which makes the above statement accurate in a twisted
way.

There needs a bit more explanation on the "should" part, especially
because this is very unusual and unlike all the other capabilities,
which are offered as more freedom of choices without preference on
the advertising side.  Rationale (i.e. reduce load on the receiving
end) and ramifications of non-compliance (e.g. the receiver may
choose to fail the push when its load is too high) are good things
to guide third-party implementors to do the right thing.

>  This capability does not include multi-base tree support.
> diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
> index e3eb5fc..288b0bc 100644
> --- a/builtin/receive-pack.c
> +++ b/builtin/receive-pack.c
> @@ -130,10 +130,11 @@ static void show_ref(const char *path, const unsigned char *sha1)
>  	if (sent_capabilities)
>  		packet_write(1, "%s %s\n", sha1_to_hex(sha1), path);
>  	else
> -		packet_write(1, "%s %s%c%s%s agent=%s\n",
> +		packet_write(1, "%s %s%c%s%s%s agent=%s\n",
>  			     sha1_to_hex(sha1), path, 0,
>  			     " report-status delete-refs side-band-64k quiet",
>  			     prefer_ofs_delta ? " ofs-delta" : "",
> +			     core_default_pack_version == 4 ? " packv4" : "",
>  			     git_user_agent_sanitized());
>  	sent_capabilities = 1;
>  }
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]