Subject: Re: Regression in `git diff --quiet HEAD` when a new file is staged

From: Jeff King <[email-masked]>
Date: Wed, 22 Oct 2025 05:14:33 -0400

On Wed, Oct 22, 2025 at 12:46:55PM +0800, Lidong Yan wrote:

> Junio C Hamano <[email-masked]> writes:
> > 
> > /* return 1 if any change is found; otherwise, return 0 */
> > static int diff_flush_patch_quietly(struct diff_filepair *p, struct diff_options *o)
> > {
> > @@ -6179,6 +6181,15 @@ static int diff_flush_patch_quietly(struct diff_filepair *p, struct diff_options
> > int saved_found_changes = o->found_changes;
> > int ret;
> > 
> > + /*
> > + * 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(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.

We probably also need to restore o->color_moved, too.

In the long run (and this is the kind of cleanup I was hoping you'd work
on for 'master'), we probably could drop that line entirely and just
skip running the moved-line detection when dry_run is set. Assuming it
even runs at all. From a quick look at the code, it looks like we only
do color-moved handling via diff_flush_patch_all_file_pairs(), so it
wouldn't trigger at all for the cases that do individual calls to
diff_flush_patch_quietly()?

-Peff