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

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 18, 2025, 15:23 UTC
Message-ID: <xmqqh5vww7xa.fsf@gitster.g>
In-Reply-To: <20251018094037.GA1060824@coredump.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 6 quoted lines

> I'm not sure which of these you mean:
>
>   - Do we still need to call diff_flush_patch_quietly() directly below
>     the hunk above, in diff_flush()?
>
>   - Do we still need the dry-run code at all?

Both. We do not have to call flush_quietly() and can call the real thing with output disabled. The dry-run bit was only added to implement the flush_quietly() variant. If we lose the only caller to flush_quietly(), all of the supporting infrastructure can go.

It concentrates only on the regression-fix aspect of the changes. Going forward, my preference is:

 * Apply your patch.  This is the base of the fix for 'maint' and
   all branches.

 * As Lidong updates dry-run code by adding more "ah we are in
   dry-run, so we should stop at the first change and se should be
   silent" fixes, we can queue them on the 'master' front for the
   preparation for a better future.  Note that the 'master' front
   would contain your "In from_contents modes, run flush_quietly()
   with output redirected to /dev/null".

 * Once we regain enough confidence for dry-run with the above
   effort, we mark your "why not redirect to /dev/null for extra
   protection?" code with NEEDSWORK comment to be removed after a
   thorough code audit to ensure that dry-run is now sound.

And I do not mind if the NEEDSWORK comment stay there for extended period of time.

Thanks.