Re: [PATCH 07/10] receive-pack: request for packv4 if it's the preferred version
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Oct 17, 2013, 17:26 UTC
- Message-ID
- <xmqqzjq724hu.fsf@gitster.dls.corp.google.com>
- In-Reply-To
- <1380162409-18224-8-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
Show 20 quoted lines
> 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@gmail.com> > --- > 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.
Show 18 quoted lines
> 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; > }