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

[Junio C Hamano <gitster@pobox.com>]

Jeff King <peff@peff.net> writes:

> 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.