All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Tan <jonathantanmy@google.com>
To: gitster@pobox.com
Cc: jonathantanmy@google.com, git@vger.kernel.org
Subject: Re: [PATCH 2/4] sideband: reverse its dependency on pkt-line
Date: Tue, 15 Jan 2019 10:36:42 -0800	[thread overview]
Message-ID: <20190115183642.253201-1-jonathantanmy@google.com> (raw)
In-Reply-To: <xmqq4labuho5.fsf@gitster-ct.c.googlers.com>

> Jonathan Tan <jonathantanmy@google.com> writes:
> 
> > +int recv_sideband(const char *me, int in_stream, int out)
> > +{
> > +	char buf[LARGE_PACKET_MAX + 1];
> > +	int retval = 0;
> > +	int len;
> > +
> > +	while (1) {
> > +		len = packet_read(in_stream, NULL, NULL, buf, LARGE_PACKET_MAX, 0);
> > +		retval = diagnose_sideband(me, buf, len);
> 
> This name of the helper does not convey much useful information.
> Let's think about it more later.

OK - after reading the later comments, switched to demultiplex_sideband.

> > +		switch (retval) {
> > +			case SIDEBAND_PRIMARY:
> 
> Dedent; case/default arms align with 's' in switch in our codebase.

Done.

> > +				break;
> > +			default: /* flush or error */
> > +				return retval;
> 
> Lack of corresponding comment bothers readers.  In all of
> REMOTE_ERROR, PROGRESS and PROTOCOL_ERROR cases, the other helper
> stuffs the message in outbuf in "switch (band) { ... }" and writes
> it out with xwrite(2, outbuf.buf, outbuf.len) [*1*], so I can see
> there is no need for us to write anything out here.  Perhaps
> 
> 		case SIDEBAND_FLUSH:
> 		default: /* errors: message already written */
> 			return retval;
> 
> or something to clarify?

Done.

> > +/*
> > + * Receive multiplexed output stream over git native protocol.
> > + * in_stream is the input stream from the remote, which carries data
> > + * in pkt_line format with band designator.  Demultiplex it into out
> > + * and err and return error appropriately.  Band #1 carries the
> > + * primary payload.  Things coming over band #2 is not necessarily
> > + * error; they are usually informative message on the standard error
> > + * stream, aka "verbose").  A message over band #3 is a signal that
> > + * the remote died unexpectedly.  A flush() concludes the stream.
> > + *
> > + * Returns SIDEBAND_FLUSH upon a normal conclusion, and SIDEBAND_PROTOCOL_ERROR
> > + * or SIDEBAND_REMOTE_ERROR if an error occurred.
> > + */
> > +int recv_sideband(const char *me, int in_stream, int out);
> 
> This is well described.

Thanks, although the credit should be given to the original author - most of
this was moved.

> > diff --git a/sideband.c b/sideband.c
> > index 368647acf8..842a92e975 100644
> > --- a/sideband.c
> > +++ b/sideband.c
> > ...
> > +int diagnose_sideband(const char *me, char *buf, int len)
> >  {
> > +	static const char *suffix;
> >  	struct strbuf outbuf = STRBUF_INIT;
> >  	int retval = 0;
> > +	const char *b, *brk;
> > +	int band;
> > +
> > +	if (!suffix) {
> > +		if (isatty(2) && !is_terminal_dumb())
> > +			suffix = ANSI_SUFFIX;
> > +		else
> > +			suffix = DUMB_SUFFIX;
> > +	}
> 
> It may be worth considering a further clean-up for the progress
> code, that consumes lines in the "switch(band)" below that are
> disproportionate to what it does in this function by introducing
> another helper function that is called from here.  When it happens,
> the above "suffix" thing should move to the helper function, too.

That's reasonable. If it's OK, I would like to limit the scope of this
patch to splitting the existing recv_sideband() into recv_sideband() and
demultiplex_sideband() (the latter is quite close to the old
recv_sideband(), and the diff looks larger only because most of it is a
dedent).

> So, the point of this helper is to inspect a single packet-line data
> and dispatch the payload of the packet based on which band it is
> sent to.  Perhaps call it with a name with demultiplex or dispatch
> in it?  "diagnose" is a bit unclear in that what trait you are
> diagnosing and for what purpose.

Changed to demultiplex_sideband.

> > +/*
> > + * buf and len should be the result of reading a line from a remote sending
> > + * multiplexed data.
> > + *
> > + * Determines the nature of the result and returns it. If
> 
> "the result" may be from the point of view of the implementor or the
> "recv_sideband()" function who called packet_read(), but a casual
> reader would perceive it more natural if you referred it as "a
> packet read from a remote".  "Inspect a packet read from the remote
> and returns which sideband it is for", perhaps?

Done.

  parent reply	other threads:[~2019-01-15 18:36 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-11 22:18 [PATCH 0/4] Sideband the whole fetch v2 response Jonathan Tan
2019-01-11 22:18 ` [PATCH 1/4] pkt-line: introduce struct packet_writer Jonathan Tan
2019-01-14 20:07   ` Junio C Hamano
2019-01-15 18:18     ` Jonathan Tan
2019-01-11 22:18 ` [PATCH 2/4] sideband: reverse its dependency on pkt-line Jonathan Tan
2019-01-14 20:07   ` Junio C Hamano
2019-01-14 22:11     ` Junio C Hamano
2019-01-15 18:38       ` Jonathan Tan
2019-01-15 18:36     ` Jonathan Tan [this message]
2019-01-11 22:18 ` [PATCH 3/4] {fetch,upload}-pack: sideband v2 fetch response Jonathan Tan
2019-01-14 22:27   ` Junio C Hamano
2019-01-15 19:18     ` Jonathan Tan
2019-01-11 22:18 ` [PATCH 4/4] tests: define GIT_TEST_SIDEBAND_ALL Jonathan Tan
2019-01-11 22:18 ` [WIP 5/4] Documentation: order protocol v2 sections Jonathan Tan
2019-01-11 22:18 ` [WIP 6/4] Documentation: add Packfile URIs design doc Jonathan Tan
2019-01-11 22:18 ` [WIP 7/4] upload-pack: refactor reading of pack-objects out Jonathan Tan
2019-01-11 22:18 ` [WIP 8/4] upload-pack: send part of packfile response as uri Jonathan Tan
2019-01-15 19:40 ` [PATCH v2 0/4] Sideband the whole fetch v2 response Jonathan Tan
2019-01-15 19:40   ` [PATCH v2 1/4] pkt-line: introduce struct packet_writer Jonathan Tan
2019-01-15 19:40   ` [PATCH v2 2/4] sideband: reverse its dependency on pkt-line Jonathan Tan
2019-01-16 10:34     ` SZEDER Gábor
2019-01-16 17:43       ` Jonathan Tan
2019-01-16 19:17         ` SZEDER Gábor
2019-01-15 19:40   ` [PATCH v2 3/4] {fetch,upload}-pack: sideband v2 fetch response Jonathan Tan
2019-01-15 19:40   ` [PATCH v2 4/4] tests: define GIT_TEST_SIDEBAND_ALL Jonathan Tan
2019-01-15 19:50   ` [PATCH v2 0/4] Sideband the whole fetch v2 response Junio C Hamano
2019-01-15 21:11   ` Junio C Hamano
2019-01-15 22:08     ` Jonathan Tan
2019-01-15 22:35       ` Junio C Hamano
2019-01-15 23:02         ` Jonathan Tan
2019-01-15 23:13           ` Junio C Hamano
2019-01-16  0:38             ` Jonathan Tan
2019-01-16  4:12               ` Junio C Hamano
2019-01-16 19:28 ` [PATCH v3 " Jonathan Tan
2019-01-16 19:28   ` [PATCH v3 1/4] pkt-line: introduce struct packet_writer Jonathan Tan
2019-01-16 19:28   ` [PATCH v3 2/4] sideband: reverse its dependency on pkt-line Jonathan Tan
2019-01-16 19:28   ` [PATCH v3 3/4] {fetch,upload}-pack: sideband v2 fetch response Jonathan Tan
2019-01-16 19:28   ` [PATCH v3 4/4] tests: define GIT_TEST_SIDEBAND_ALL Jonathan Tan
2019-01-29 23:27     ` Jonathan Nieder
2019-02-13  6:49       ` Jeff King
2019-01-17 19:43   ` [PATCH v3 0/4] Sideband the whole fetch v2 response Junio C Hamano

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=20190115183642.253201-1-jonathantanmy@google.com \
    --to=jonathantanmy@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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.