All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sergey Organov <sorganov@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] diff: fix behaviour of the "-s" option
Date: Fri, 05 May 2023 11:32:51 +0300	[thread overview]
Message-ID: <87sfcbyy8c.fsf@osv.gnss.ru> (raw)
In-Reply-To: <xmqqfs8bith1.fsf_-_@gitster.g> (Junio C. Hamano's message of "Thu, 04 May 2023 16:10:02 -0700")

Junio C Hamano <gitster@pobox.com> writes:

> Junio C Hamano <gitster@pobox.com> writes:
>
>> I haven't run any tests (not just your new one, but existing ones)
>> but ...
>
> And of course, not writing tests fails to even realize that the bug
> has two components, "-s" failing to clear the bits previously set,
> and other options not clearing the bit set by "-s".
>
> This version may still be rough, but at least the full test suite
> has been run with it, so I have a bit more confidence than the
> earlier one (which may not mean much).
>
> ------- >8 ------------- >8 ------------- >8 -------------
> Sergey Organov noticed and reported "--patch --no-patch --raw"
> behaves differently from "--raw".  It turns out there are a few
> interesting bugs in the implementation and documentation.
>
>  * First, the documentation for "--no-patch" was unclear that it
>    could be read to mean "--no-patch" countermands an earlier
>    "--patch" but not other things.  The intention of "--no-patch"
>    ever since it was introduced at d09cd15d (diff: allow --no-patch
>    as synonym for -s, 2013-07-16) was to serve as a synonym for
>    "-s", so "--raw --patch --no-patch" should have produced no
>    output, but it can be (mis)read to allow showing only "--raw"
>    output.
>
>  * Then the interaction between "-s" and other format options were
>    poorly implemented.  Modern versions of Git uses one bit each to
>    represent formatting options like "--patch", "--stat" in a single
>    output_format word, but for historical reasons, "-s" also is
>    represented as another bit in the same word.  This allows two
>    interesting bugs to happen, and we have both.
>
>    (1) After setting a format bit, then setting NO_OUTPUT with "-s",
>        the code to process another "--<format>" option drops the
>        NO_OUTPUT bit to allow output to be shown again.  However,
>        the code to handle "-s" only set NO_OUTPUT without unsetting
>        format bits set earlier, so the earlier format bit got
>        revealed upon seeing the second "--<format>" option.  THis is
>        the problem Sergey observed.
>
>    (2) After setting NO_OUTPUT with "-s", code to process
>        "--<format>" option can forget to unset NO_OUTPUT, leaving
>        the command still silent.
>
> It is tempting to change the meaning of "--no-patch" to mean
> "disable only the patch format output" and reimplement "-s" as "not
> showing anything", but it would be an end-user visible change in
> behaviour.  Let's fix the interactions of these bits to first make
> "-s" work as intended.
>
> The fix is conceptually very simple.
>
>  * Whenever we set DIFF_FORMAT_FOO becasuse we saw the "--foo"
>    option (e.g. DIFF_FORMAT_RAW is set when the "--raw" option is
>    given), we make sure we drop DIFF_FORMAT_NO_OUTPUT.  We forgot to
>    do so in some of the options and caused (2) above.
>
>  * When processing "-s" option, we should not just set
>    DIFF_FORMAT_NO_OUTPUT bit, but clear other DIFF_FORMAT_* bits.
>    We didn't do so and retained format bits set by options
>    previously seen, causing (1) above.

Sounds good to me. Doesn't this makes DIFF_FORMAT_NO_OUTPUT obsolete as
well, I wonder, as absence of any output bits effectively means "no
output"?

Thanks,
-- Sergey Organov

  parent reply	other threads:[~2023-05-05  8:33 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-03 13:41 [PATCH] t4013: add expected failure for "log --patch --no-patch" Sergey Organov
2023-05-03 16:57 ` Junio C Hamano
2023-05-03 17:31   ` Sergey Organov
2023-05-03 18:07     ` Junio C Hamano
2023-05-03 18:32       ` Felipe Contreras
2023-05-03 19:49       ` Sergey Organov
2023-05-04 15:50       ` Junio C Hamano
2023-05-04 18:24         ` Sergey Organov
2023-05-04 20:53           ` Junio C Hamano
2023-05-04 21:37             ` Re* " Junio C Hamano
2023-05-04 23:10               ` [PATCH] diff: fix behaviour of the "-s" option Junio C Hamano
2023-05-05  5:28                 ` Junio C Hamano
2023-05-05 16:51                   ` Junio C Hamano
2023-05-09  1:16                   ` Felipe Contreras
2023-05-05  8:32                 ` Sergey Organov [this message]
2023-05-05 16:31                   ` Junio C Hamano
2023-05-05 17:07                     ` Sergey Organov
2023-05-05 16:59                 ` [PATCH v2] diff: fix interaction between the "-s" option and other options Junio C Hamano
2023-05-05 17:41                   ` Eric Sunshine
2023-05-05 19:01                     ` Junio C Hamano
2023-05-05 21:19                   ` [PATCH 0/2] dirstat: leakfix Junio C Hamano
2023-05-05 21:19                     ` [PATCH 1/2] diff: refactor common tail part of dirstat computation Junio C Hamano
2023-05-05 21:19                     ` [PATCH 2/2] diff: plug leaks in dirstat Junio C Hamano
2023-05-09  0:38                   ` [PATCH v2] diff: fix interaction between the "-s" option and other options Felipe Contreras
2023-05-09  1:22                     ` Junio C Hamano
2023-05-09  3:50                       ` Felipe Contreras
2023-05-10  4:26                         ` Junio C Hamano
2023-05-10 23:16                           ` Felipe Contreras
2023-05-10 23:41                             ` Felipe Contreras
2023-05-11  1:25                               ` Jeff King
2023-05-13  3:07                                 ` Felipe Contreras
2023-05-11  1:50                             ` Junio C Hamano
2023-05-13  5:32                               ` Felipe Contreras
2023-05-09  1:34           ` [PATCH] t4013: add expected failure for "log --patch --no-patch" Felipe Contreras
2023-05-10 13:54             ` Sergey Organov
2023-05-10 21:54               ` Felipe Contreras
2023-05-09  1:03         ` Felipe Contreras
2023-05-04 18:07   ` Junio C Hamano
2023-05-04 18:26     ` Sergey Organov
2023-05-09  1:07     ` Felipe Contreras
2023-05-10 13:40       ` Sergey Organov
2023-05-10 21:39         ` Felipe Contreras

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=87sfcbyy8c.fsf@osv.gnss.ru \
    --to=sorganov@gmail.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.