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

From: Jeff King <peff@peff.net>
Date: Oct 22, 2025, 09:11 UTC
Message-ID: <20251022091112.GB853931@coredump.intra.peff.net>
In-Reply-To: <xmqqy0p4wcac.fsf@gitster.g>

On Tue, Oct 21, 2025 at 07:38:03AM -0700, Junio C Hamano wrote:

Show 6 quoted lines

> > So really, the regression fix should probably cover both of them (which
> > it would if we move the /dev/null redirection into the flush_quietly()
> > variant).
> 
> Do you mean something like this on top of your patch for 'maint',
> and the latest from Lidong to the 'master' front, then?

Yep, exactly (though with the "o->file" restoration that Lidong pointed out).

Show 5 quoted lines

> Having calls to this helper in two loops in one function looks a bit
> awkward but the conditions to enter these two loops are mutually
> exclusive, so it is not like we can remember the result of the calls
> we make in the first loop and reuse in the second loop, so this
> probably is the best we can do.

Yeah. I suspect there is some formulation along the lines of: if we have diff_from_contents set but are not looking at a content-level diff, then up-front in diff_flush() we should quietly flush each to find out what is changed and what is not. But the loop for NAME_STATUS, etc, needs to know _which_ pairs still had changes (whereas --quiet only cares about whether there were any changes at all). So we'd have to store that somewhere.

And of course the chance of regressing some unconsidered corner case is high. Definitely not something we should entertain while doing another regression fix. ;)

-Peff