All of lore.kernel.org
 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: Thu, 23 Oct 2025 06:35:05 -0700	[thread overview]
Message-ID: <xmqqms5hwxkm.fsf@gitster.g> (raw)
In-Reply-To: <20251023120101.GA1123594@coredump.intra.peff.net> (Jeff King's message of "Thu, 23 Oct 2025 08:01:01 -0400")

Jeff King <peff@peff.net> writes:

> That is because you are trying to redirect to /dev/null once at the
> beginning of the loop. But the loop is effectively:
>
>   for each pair
>     check for content changes with diff_flush_patch_quietly();
>     output actual pair data with flush_one_pair();
>
> We want the redirection to /dev/null for the first part of the loop
> body, but not the second. So you have to do the redirection inside the
> loop.

Yeah, my bad.  Lidong noticed the same thing.

> I agree that opening /dev/null over and over is silly. But we can reuse
> the same filehandle for each one. I.e., like:
>
> diff --git a/diff.c b/diff.c
> index dac3ea9e01..e903afcf04 100644
> --- a/diff.c
> +++ b/diff.c
> @@ -6835,11 +6835,11 @@ void diff_flush(struct diff_options *options)
>  		/*
>  		 * make sure diff_Flush_patch_quietly() to be silent.
>  		 */
> -		FILE *saved_file = options->file;
> +		FILE *dev_null = NULL;
>  		int saved_color_moved = options->color_moved;
>  
>  		if (options->flags.diff_from_contents) {
> -			options->file = xfopen("/dev/null", "w");
> +			dev_null = xfopen("/dev/null", "w");
>  			options->color_moved = 0;
>  		}
>  		for (i = 0; i < q->nr; i++) {
> @@ -6848,15 +6848,20 @@ void diff_flush(struct diff_options *options)
>  			if (!check_pair_status(p))
>  				continue;
>  
> -			if (options->flags.diff_from_contents &&
> -			    !diff_flush_patch_quietly(p, options))
> -				continue;
> +			if (options->flags.diff_from_contents) {
> +				FILE *saved_file = options->file;
> +				int r;
> +				options->file = dev_null;
> +				r = diff_flush_patch_quietly(p, options);
> +				options->file = saved_file;
> +				if (!r)
> +					continue;
> +			}
>  
>  			flush_one_pair(p, options);
>  		}
>  		if (options->flags.diff_from_contents) {
> -			fclose(options->file);
> -			options->file = saved_file;
> +			fclose(dev_null);
>  			options->color_moved = saved_color_moved;
>  		}
>  		separator++;
>
> You could even imagine diff_flush_patch_quietly() saving the /dev/null
> descriptor in a static variable and effectively leaking it (or if we
> want to be more structured, cached inside the diff_options struct). And
> then the callers do not have to worry about it at all.

That would be bigger change than a regression fix warrants, so let's
leave it out, but let me use the above to replace my botched
attempt.

Thanks, both of you.


  parent reply	other threads:[~2025-10-23 13:35 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
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 [this message]
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=xmqqms5hwxkm.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.