git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: Jake Zimmerman <jake@zimmerman.io>,
	 Lidong Yan <yldhome2d2@gmail.com>,
	git@vger.kernel.org
Subject: Re: Regression in `git diff --quiet HEAD` when a new file is staged
Date: Fri, 17 Oct 2025 10:45:12 -0700	[thread overview]
Message-ID: <xmqq7bwt1kyf.fsf@gitster.g> (raw)
In-Reply-To: <20251017075153.GA4078773@coredump.intra.peff.net> (Jeff King's message of "Fri, 17 Oct 2025 03:51:53 -0400")

Jeff King <peff@peff.net> writes:

> Looking at that patch, my biggest concern is: are we missing other spots
> that need to special-case the dry_run setting? Because it's a regression
> in a maint release, I'm tempted to say we should do the dumbest possible
> thing that covers all cases and just revert this hunk from the original
> patch, like:
>
> diff --git a/diff.c b/diff.c
> index 87fa16b730..687206f353 100644
> --- a/diff.c
> +++ b/diff.c
> @@ -6890,6 +6890,15 @@ void diff_flush(struct diff_options *options)
>  	if (output_format & DIFF_FORMAT_NO_OUTPUT &&
>  	    options->flags.exit_with_status &&
>  	    options->flags.diff_from_contents) {
> +		/*
> +		 * run diff_flush_patch for the exit status. setting
> +		 * options->file to /dev/null should be safe, because we
> +		 * aren't supposed to produce any output anyway.
> +		 */
> +		diff_free_file(options);
> +		options->file = xfopen("/dev/null", "w");
> +		options->close_file = 1;
> +		options->color_moved = 0;
>  		for (i = 0; i < q->nr; i++) {
>  			struct diff_filepair *p = q->queue[i];
>  			if (check_pair_status(p))
>
> That would catch the bug here, as well as any others lurking. And it
> converts any missing dry_run from correctness problems (we definitely
> will not produce extra output) into optimization problems (we might emit
> data we do not need, but we can fix those separately). At least for the
> normal code paths. I think without those extra fixes the problems that
> b55e6d36eb tried to fix for "-I" would still be observable, but at least
> its fixes could not regress the other code paths.

Ahh.  I like this "stupid but cannot be incorrect" version even
better than the original one that introduced the "dry run" mode.

But once we go in that direction, do we still need the dry-run
machinery with diff_flush_patch_quietly() helper function?


  parent reply	other threads:[~2025-10-17 17:45 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-17  0:09 Regression in `git diff --quiet HEAD` when a new file is staged Jake Zimmerman
2025-10-17  7:51 ` Jeff King
2025-10-17  8:36   ` [PATCH] diff: restore redirection to /dev/null for diff_from_contents Jeff King
2025-10-17 18:22     ` Junio C Hamano
2025-10-19 21:09     ` Johannes Schindelin
2025-10-21  7:52       ` Jeff King
2025-10-17 11:44   ` Regression in `git diff --quiet HEAD` when a new file is staged Johannes Schindelin
2025-10-17 17:45   ` Junio C Hamano [this message]
2025-10-18  1:04     ` Lidong Yan
2025-10-18  9:42       ` Jeff King
2025-10-18  9:40     ` Jeff King
2025-10-18 15:23       ` Junio C Hamano
2025-10-21  7:36         ` Jeff King
2025-10-21 14:38           ` Junio C Hamano
2025-10-22  4:46             ` Lidong Yan
2025-10-22  9:14               ` Jeff King
2025-10-22 14:20                 ` Lidong Yan
2025-10-22 14:31               ` Junio C Hamano
2025-10-22 16:28                 ` Junio C Hamano
2025-10-22  9:11             ` Jeff King
2025-10-22 16:48               ` Junio C Hamano
2025-10-23 12:01                 ` Jeff King
2025-10-23 12:15                   ` Jeff King
2025-10-23 13:35                   ` Junio C Hamano
2025-10-22 17:39             ` Junio C Hamano
2025-10-23  0:33               ` Lidong Yan
2025-10-23 13:42                 ` 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=xmqq7bwt1kyf.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=jake@zimmerman.io \
    --cc=peff@peff.net \
    --cc=yldhome2d2@gmail.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 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 NNTP newsgroup(s).