All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>, Lidong Yan <yldhome2d2@gmail.com>
Cc: Jake Zimmerman <jake@zimmerman.io>,  git@vger.kernel.org
Subject: Re: Regression in `git diff --quiet HEAD` when a new file is staged
Date: Wed, 22 Oct 2025 09:28:20 -0700	[thread overview]
Message-ID: <xmqqms5izysb.fsf@gitster.g> (raw)
In-Reply-To: <xmqqa51j0zzj.fsf@gitster.g> (Junio C. Hamano's message of "Wed, 22 Oct 2025 07:31:44 -0700")

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

> Lidong Yan <yldhome2d2@gmail.com> writes:
>
>>> + diff_free_file(o);
>>> + o->file = xfopen("/dev/null", "w");
>>> + o->close_file = 1;
>>> + o->color_moved = 0;
>>> o->dry_run = 1;
>>> o->found_changes = 0;
>>> diff_flush_patch(p, o);
>>> 
>>
>> This would make everything going to "/dev/null" after the flush_quietly() call.
>> I think we need to restore o->file.
>
> Ah, true, the original location was only for NO_OUTPUT but the other
> caller to the diff_flush_patch_quietly() helper does deal with other
> cases as well.

Now it turns out to be rather ugly, having to go back and forth on a
few members of the diff_options structure.  I suspect there are
members other than color_moved that would not affect the outcome
(like --word-diff and --color-words) that cost us without giving any
benefit in this context that we may want to disable, but that would
make it even uglier.

I am having second thoughts on this approach to move the redirection
to patch_quietly(), which means for N-path change, we end up /dev/null
redirection N times.  We have two callers, so we may be better off
having the redirection around the loops that contain these callers?

I dunno.


 diff.c | 23 ++++++++++++++---------
 1 file changed, 14 insertions(+), 9 deletions(-)

diff --git c/diff.c w/diff.c
index 9b8d658b9e..d28f69e5ce 100644
--- c/diff.c
+++ w/diff.c
@@ -6177,14 +6177,28 @@ static int diff_flush_patch_quietly(struct diff_filepair *p, struct diff_options
 {
 	int saved_dry_run = o->dry_run;
 	int saved_found_changes = o->found_changes;
+	int saved_color_moved = o->color_moved;
+	FILE *saved_file = o->file;
 	int ret;
 
+	/*
+	 * Do the dry-run check while sending output to /dev/null and
+	 * extra computation like color_moved that would not change
+	 * the final outcome disabled.
+	 */
+	o->file = xfopen("/dev/null", "w");
+	o->color_moved = 0;
 	o->dry_run = 1;
 	o->found_changes = 0;
+
 	diff_flush_patch(p, o);
 	ret = o->found_changes;
+	fclose((o->file);
+
 	o->dry_run = saved_dry_run;
 	o->found_changes |= saved_found_changes;
+	o->color_moved = saved_color_moved;
+	o->file = saved_file;
 	return ret;
 }
 
@@ -6876,15 +6890,6 @@ 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))

  reply	other threads:[~2025-10-22 16:28 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
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 [this message]
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=xmqqms5izysb.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 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.