From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: git@vger.kernel.org, Paul Watson <pwatson2@wellmed.net>
Subject: Re: [PATCH] diff: tighten interaction between -w and --exit-code
Date: Thu, 17 Aug 2023 09:12:09 -0700 [thread overview]
Message-ID: <xmqqy1i9bqcm.fsf@gitster.g> (raw)
In-Reply-To: <20230817051059.GA3006160@coredump.intra.peff.net> (Jeff King's message of "Thu, 17 Aug 2023 01:10:59 -0400")
Jeff King <peff@peff.net> writes:
> For the diffstat case, I think we could check the mode here, but there
> are other cases (e.g., adding or deleting an empty file). The code right
> below the hunk I quoted seems to try to deal with that (the "cancelling
> the no-op" your comment mentions). I'm not sure if we want something
> like this:
>
> diff --git a/diff.c b/diff.c
> index 38b57b589f..1dbfdaeff0 100644
> --- a/diff.c
> +++ b/diff.c
> @@ -3853,6 +3853,8 @@ static void builtin_diffstat(const char *name_a, const char *name_b,
> && one->mode == two->mode) {
> free_diffstat_file(file);
> diffstat->nr--;
> + } else {
> + o->found_changes = 1;
> }
> }
> }
That is much better. In all cases where the above diffstat->nr-- is
not reached and diffstat is kept is where we found changes, so an
even simpler solution that fundamentally cannot go wrong would be to
see "diffstat->nr" at the end (i.e. "are we going to show diffstat
for *any* filepair?"). If it is non-zero, we did find a difference.
Then we do not have to wonder if that else clause is in the right
place, or we have to do something similar to the above for cases
where DIFF_FILE_VALID() is not true for both sides (i.e. creation or
deletion).
Thanks.
next prev parent reply other threads:[~2023-08-17 16:13 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-04 16:46 git bug report Paul Watson
2023-08-04 17:28 ` rsbecker
2023-08-04 17:48 ` [EXTERNAL] " Paul Watson
2023-08-04 18:12 ` rsbecker
2023-08-07 15:46 ` Paul Watson
2023-08-08 13:07 ` Paul Watson
2023-08-08 13:28 ` rsbecker
2023-08-08 17:07 ` Junio C Hamano
2023-08-16 23:45 ` [PATCH] diff: tighten interaction between -w and --exit-code Junio C Hamano
2023-08-17 5:10 ` Jeff King
2023-08-17 16:12 ` Junio C Hamano [this message]
2023-08-17 19:49 ` Jeff King
2023-08-17 19:56 ` Junio C Hamano
2023-08-17 22:29 ` [PATCH v2 0/5] fix interactions with "-w" and "--exit-code" Junio C Hamano
2023-08-17 22:29 ` [PATCH v2 1/5] diff: --dirstat leakfix Junio C Hamano
2023-08-17 22:29 ` [PATCH v2 2/5] diff: move the fallback "--exit-code" code down Junio C Hamano
2023-08-17 22:29 ` [PATCH v2 3/5] diff: mode-only change should be noticed by "--patch -w --exit-code" Junio C Hamano
2023-08-18 21:15 ` Junio C Hamano
2023-08-17 22:29 ` [PATCH v2 4/5] diff: teach "--stat -w --exit-code" to notice differences Junio C Hamano
2023-08-17 22:29 ` [PATCH v2 5/5] diff: teach "--name-status" and friends to honor "--exit-code -w" Junio C Hamano
2023-08-17 22:37 ` [PATCH v2 0/5] fix interactions with "-w" and "--exit-code" Junio C Hamano
2023-08-18 23:59 ` [PATCH v3 " Junio C Hamano
2023-08-18 23:59 ` [PATCH v3 1/5] diff: move the fallback "--exit-code" code down Junio C Hamano
2023-08-21 20:41 ` Jeff King
2023-08-18 23:59 ` [PATCH v3 2/5] diff: mode-only change should be noticed by "--patch -w --exit-code" Junio C Hamano
2023-08-18 23:59 ` [PATCH v3 3/5] diff: teach "--stat -w --exit-code" to notice differences Junio C Hamano
2023-08-21 20:45 ` Jeff King
2023-08-18 23:59 ` [PATCH v3 4/5] t4040: remove test that succeeded for a wrong reason Junio C Hamano
2023-08-18 23:59 ` [PATCH v3 5/5] diff: the -w option breaks --exit-code for --raw and other output modes Junio C Hamano
2023-08-21 21:00 ` Jeff King
2023-08-21 21:08 ` Jeff King
2023-08-21 22:23 ` Jeff King
2023-08-21 22:16 ` Junio C Hamano
2023-08-21 22:26 ` Junio C Hamano
2023-08-22 1:30 ` Jeff King
2023-08-21 21:02 ` [PATCH v3 0/5] fix interactions with "-w" and "--exit-code" Jeff King
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=xmqqy1i9bqcm.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=peff@peff.net \
--cc=pwatson2@wellmed.net \
/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.