From: Brandon Williams <bmwill@google.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: [WIP 07/15] connect: convert get_remote_heads to use struct packet_reader
Date: Fri, 8 Dec 2017 12:19:30 -0800 [thread overview]
Message-ID: <20171208201930.GD140529@google.com> (raw)
In-Reply-To: <xmqqh8t3fpm7.fsf@gitster.mtv.corp.google.com>
On 12/06, Junio C Hamano wrote:
> Brandon Williams <bmwill@google.com> writes:
>
>
> EXPECTING_DONE sounded like we are expecting to see 'done' packet
> sent from the other side, but I was mistaken. It is the state
> where we are "done" expecting anything ;-).
>
> Having an (unconditional) assignment to 'state' in the above switch
> makes me feel somewhat uneasy, as the next "switch (state)" is what
> is meant as the state machine that would allow us to say things like
> "from this state, transition to that state is impossible". When we
> get a flush while we are expecting the first ref, for example, we'd
> just go into the "done" state. There is no provision for a future
> update to say "no, getting a flush in this state is an error".
I believe this is accepted behavior, receiving a flush in that state.
And I don't think there is ever an instance during the ref advertisement
where a flush would be an error. It just indicates that the
advertisement is finished.
>
> That is no different from the current code; when read_remote_ref()
> notices that it got a flush, it just leaves the loop without even
> touching 'state' variable. But at least, I find that the current
> code is more honest---it does not even touch 'state' and allows the
> code after the loop to inspect it, if needed. From that point of
> vhew, the way the new code uses 'state' to leave the loop upon
> seeing a flush is a regression---it makes it harder to notice and
> report when we got a flush in a wrong state.
>
> Perhaps getting rid of "EXPECTING_DONE" from the enum and then:
>
> int got_flush = 0;
> while (1) {
> switch (reader_read()) {
> case PACKET_READ_FLUSH:
> got_flush = 1;
> break;
> ... other cases ...
> }
>
> if (got_flush)
> break;
>
> switch (state) {
> ... current code ...
> }
> }
>
> would be an improvement; we can later extend "if (got_flush)" part
> to check what state we are in if we wanted to notice and report an
> error there before breaking out of the loop.
>
I don't really see how this is any clearer from what this patch does
though. I thought it made it easier to read as you no longer have an
infinite loop, but rather know when it will end (when you move to the
done state).
--
Brandon Williams
next prev parent reply other threads:[~2017-12-08 20:19 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-20 17:18 [RFC] protocol version 2 Brandon Williams
2017-10-24 6:48 ` Junio C Hamano
2017-10-24 18:35 ` Brandon Williams
2017-10-25 1:22 ` Junio C Hamano
2017-10-26 0:59 ` Junio C Hamano
2017-10-25 13:09 ` Derrick Stolee
2017-10-25 18:10 ` Brandon Williams
2017-10-28 22:57 ` Philip Oakley
2017-10-31 18:42 ` Brandon Williams
2017-11-10 20:13 ` Jonathan Tan
2017-12-04 23:58 ` [WIP 00/15] " Brandon Williams
2017-12-04 23:58 ` [WIP 01/15] pkt-line: introduce packet_read_with_status Brandon Williams
2017-12-07 20:53 ` Stefan Beller
2017-12-08 18:03 ` Brandon Williams
2017-12-04 23:58 ` [WIP 02/15] pkt-line: introduce struct packet_reader Brandon Williams
2017-12-07 22:01 ` Stefan Beller
2017-12-08 18:11 ` Brandon Williams
2017-12-04 23:58 ` [WIP 03/15] pkt-line: add delim packet support Brandon Williams
2017-12-07 22:30 ` Stefan Beller
2017-12-08 20:08 ` Brandon Williams
2017-12-04 23:58 ` [WIP 04/15] upload-pack: convert to a builtin Brandon Williams
2017-12-06 21:59 ` Junio C Hamano
2017-12-07 16:14 ` Johannes Schindelin
2017-12-08 20:26 ` Junio C Hamano
2017-12-08 20:12 ` Brandon Williams
2017-12-04 23:58 ` [WIP 05/15] upload-pack: factor out processing lines Brandon Williams
2017-12-04 23:58 ` [WIP 06/15] transport: use get_refs_via_connect to get refs Brandon Williams
2017-12-06 22:10 ` Junio C Hamano
2017-12-07 18:40 ` Brandon Williams
2017-12-04 23:58 ` [WIP 07/15] connect: convert get_remote_heads to use struct packet_reader Brandon Williams
2017-12-06 22:39 ` Junio C Hamano
2017-12-08 20:19 ` Brandon Williams [this message]
2017-12-04 23:58 ` [WIP 08/15] connect: discover protocol version outside of get_remote_heads Brandon Williams
2017-12-07 18:50 ` Junio C Hamano
2017-12-07 19:04 ` Brandon Williams
2017-12-07 19:30 ` Junio C Hamano
2017-12-08 20:11 ` Brandon Williams
2017-12-04 23:58 ` [WIP 09/15] transport: store protocol version Brandon Williams
2017-12-04 23:58 ` [WIP 10/15] protocol: introduce enum protocol_version value protocol_v2 Brandon Williams
2017-12-04 23:58 ` [WIP 11/15] serve: introduce git-serve Brandon Williams
2017-12-07 23:42 ` Junio C Hamano
2017-12-08 20:25 ` Brandon Williams
2017-12-04 23:58 ` [WIP 12/15] ls-refs: introduce ls-refs server command Brandon Williams
2017-12-13 16:30 ` Philip Oakley
2017-12-04 23:58 ` [WIP 13/15] connect: request remote refs using v2 Brandon Williams
2017-12-04 23:58 ` [WIP 14/15] upload_pack: introduce fetch server command Brandon Williams
2017-12-04 23:58 ` [WIP 15/15] fetch-pack: perform a fetch using v2 Brandon Williams
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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20171208201930.GD140529@google.com \
--to=bmwill@google.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
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 read-only IMAP folder(s) and NNTP newsgroup(s).