All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Lars Schneider <larsxschneider@gmail.com>
Cc: git@vger.kernel.org, peff@peff.net, tboegi@web.de, e@80x24.org,
	ttaylorr@github.com, peartben@gmail.com
Subject: Re: [PATCH v6 3/6] t0021: write "OUT" only on success
Date: Mon, 26 Jun 2017 10:50:09 -0700	[thread overview]
Message-ID: <xmqqr2y663la.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <0FC46284-650F-411D-845F-0DF4F32071FF@gmail.com> (Lars Schneider's message of "Mon, 26 Jun 2017 11:26:30 +0200")

Lars Schneider <larsxschneider@gmail.com> writes:

>> On 26 Jun 2017, at 00:17, Junio C Hamano <gitster@pobox.com> wrote:
>> 
>> Lars Schneider <larsxschneider@gmail.com> writes:
>> 
>>> "rot13-filter.pl" used to write "OUT <size>" to the debug log even in case of
>>> an abort or error. Fix this by writing "OUT <size>" to the debug log only in
>>> the successful case if output is actually written.
>> 
>> Again, use of "Fix this" without clarifying what the problem is.  Is
>> this change needed because the size may not be known when the new
>> filter protocol is in use, or something?
>
> How about this?
>
>     "rot13-filter.pl" always writes "OUT <size>" to the debug log at the end
>     of an interaction.
>
>     This works without issues for the existing cases "abort", "error", and 
>     "success". In a subsequent patch 'convert: add "status=delayed" to 
>     filter process protocol' we will add a new case "delayed". In that case 
>     we do not send the data right away and it would be wrong/misleading to
>     the reader if we would write "OUT <size>" to the debug log.

I still do not quite get "we do not send the data right away" as
opposed to "at the end of an interaction" makes it wrong/misleading
to write "OUT <size>"?

    A new response "delayed" that will be introduced in subsequent
    patches accepts the input, without giving the filtered result
    right away, and at that moment, we do not even have the output
    size yet.

might be a very reasonable rationale for omitting "OUT: <size>" in
the output when "delayed" request is seen, but that still does not
explain why it is sensible to drop "OUT: <size>" for error or abort
case.

Having said all that, I tend to agree with the actual change.  When
we abort or error, we aren't producing any useful output, so it may
be sensible _not_ to say "OUT: 0" in the log output from the test
helper in these cases.  And if the change is explained that way,
readers would understand why this step is a good thing to have, with
or without the future "delayed" step in the series.

Thanks.

  reply	other threads:[~2017-06-26 17:50 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-25 18:21 [PATCH v6 0/6] convert: add "status=delayed" to filter process protocol Lars Schneider
2017-06-25 18:21 ` [PATCH v6 1/6] t0021: keep filter log files on comparison Lars Schneider
2017-06-25 22:12   ` Junio C Hamano
2017-06-26  9:02     ` Lars Schneider
2017-06-26 17:31       ` Junio C Hamano
2017-06-25 18:21 ` [PATCH v6 2/6] t0021: make debug log file name configurable Lars Schneider
2017-06-25 22:15   ` Junio C Hamano
2017-06-25 18:21 ` [PATCH v6 3/6] t0021: write "OUT" only on success Lars Schneider
2017-06-25 22:17   ` Junio C Hamano
2017-06-26  9:26     ` Lars Schneider
2017-06-26 17:50       ` Junio C Hamano [this message]
2017-06-26 18:32         ` Lars Schneider
2017-06-25 18:21 ` [PATCH v6 4/6] convert: put the flags field before the flag itself for consistent style Lars Schneider
2017-06-25 22:19   ` Junio C Hamano
2017-06-25 18:21 ` [PATCH v6 5/6] convert: move multiple file filter error handling to separate function Lars Schneider
2017-06-26 17:56   ` Junio C Hamano
2017-06-27  2:51     ` Stefan Beller
2017-06-26 18:00   ` Junio C Hamano
2017-06-25 18:21 ` [PATCH v6 6/6] convert: add "status=delayed" to filter process protocol Lars Schneider
2017-06-26 19:02   ` Junio C Hamano
2017-06-26 21:28     ` Lars Schneider
2017-06-26 22:13       ` Junio C Hamano
2017-06-26 22:38         ` Junio C Hamano
2017-06-27 12:07         ` Lars Schneider

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=xmqqr2y663la.fsf@gitster.mtv.corp.google.com \
    --to=gitster@pobox.com \
    --cc=e@80x24.org \
    --cc=git@vger.kernel.org \
    --cc=larsxschneider@gmail.com \
    --cc=peartben@gmail.com \
    --cc=peff@peff.net \
    --cc=tboegi@web.de \
    --cc=ttaylorr@github.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.