From: Junio C Hamano <gitster@pobox.com>
To: Daniel Duvall <dan@mutual.io>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] upload-pack: allow stateless client EOF just prior to haves
Date: Fri, 30 Oct 2020 11:42:25 -0700 [thread overview]
Message-ID: <xmqq7dr7369a.fsf@gitster.c.googlers.com> (raw)
In-Reply-To: <1604029402-19593-1-git-send-email-dan@mutual.io> (Daniel Duvall's message of "Thu, 29 Oct 2020 20:43:22 -0700")
Daniel Duvall <dan@mutual.io> writes:
> diff --git a/upload-pack.c b/upload-pack.c
> index 3b858eb..2b128e4 100644
> --- a/upload-pack.c
> +++ b/upload-pack.c
> @@ -1344,7 +1344,18 @@ void upload_pack(struct upload_pack_options *options)
> PACKET_READ_DIE_ON_ERR_PACKET);
>
> receive_needs(&data, &reader);
> - if (data.want_obj.nr) {
> +
> + /*
> + * An EOF at this exact point in negotiation should be
> + * acceptable from stateless clients as they will consume the
> + * shallow list before doing subsequent rpc with haves/etc.
> + */
> + if (data.stateless_rpc)
> + reader.options |= PACKET_READ_GENTLE_ON_EOF;
> +
> + if (data.want_obj.nr &&
> + packet_reader_peek(&reader) != PACKET_READ_EOF) {
> + reader.options ^= PACKET_READ_GENTLE_ON_EOF;
I am a bit puzzled why it is sensible to
(1) unconditionally
(2) toggle
the GENTLE bit.
> get_common_commits(&data, &reader);
> create_pack_file(&data, NULL);
> }
If we are not doing stateless_rpc, we call get_common_commits() with
a reader that is gentle on eof, which is not an intended behaviour
change, no?
I would have understood if this were more like
if (data.stateless_rpc)
reader.options |= PACKET_READ_GENTLE_ON_EOF;
if (data.want_obj.nr &&
packet_reader_peek(&reader) != PACKET_READ_EOF) {
if (data.stateless_rpc)
reader.options &= ~PACKET_READ_GENTLE_ON_EOF;
i.e. only when we know we set the bit when the bit was originally
clear, revert to the original state.
Note. initially I thought we may need to check the original
value of the bit in reader.options before flipping it on,
but this packet_reader has freshly been initialized in the
inner block we see here, so we know that nobody other than
this new code would have set the bit.
Or for that matter, just unconditionally turn it off, e.g.
if (data.want_obj.nr &&
packet_reader_peek(&reader) != PACKET_READ_EOF) {
reader.options &= ~PACKET_READ_GENTLE_ON_EOF;
Puzzled...
next prev parent reply other threads:[~2020-10-30 18:42 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-30 1:40 [PATCH] upload-pack: allow stateless client EOF just prior to haves Daniel Duvall
2020-10-30 2:59 ` Eric Sunshine
2020-10-30 3:31 ` Daniel Duvall
2020-10-30 3:43 ` Daniel Duvall
2020-10-30 18:42 ` Junio C Hamano [this message]
2020-10-30 22:38 ` Daniel Duvall
2020-10-30 4:40 ` Jeff King
2020-10-30 7:47 ` Daniel Duvall
2020-10-30 9:09 ` Jeff King
2020-11-03 21:10 ` Junio C Hamano
2020-11-04 13:33 ` Jeff King
2020-11-04 14:06 ` Daniel Duvall
2020-11-04 18:25 ` Junio C Hamano
2020-10-30 22:35 ` [PATCH v2] " Daniel Duvall
2020-10-30 23:45 ` Junio C Hamano
2020-10-31 2:42 ` Daniel Duvall
2020-10-31 4:17 ` Junio C Hamano
2020-10-31 2:39 ` [PATCH v3] " Daniel Duvall
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqq7dr7369a.fsf@gitster.c.googlers.com \
--to=gitster@pobox.com \
--cc=dan@mutual.io \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).