Re: [PATCH v2] diff: disable rename detection with --quiet

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

Jeff King <peff@peff.net> writes:

> This makes sense to me, and I can't think of a reason why you would want
> rename detection on if we're not going to show the results (and likewise
> I can't think of a way that a rename result would affect has_changes).
>
> I wonder if we should _also_ take the hunk from v1 that teaches
> can_quit_early() to avoid triggering when copy detection is on. It's
> probably redundant now, but it feels to me like that's the place where
> the correctness check should kick in. And the patch here is just
> optimizing out the unnecessary work, but also happens to align things
> for correctness downstream.

Concurred on both counts.

> You don't say in the commit message when this bug started. I briefly
> wondered if it was caused by the recent diff_from_contents stuff we've
> been discussing. But it's the opposite here (the bug happens when we
> _don't_ set diff_from_contents). And I think it goes all the way back to
> b4194828dc (diff-index --quiet: learn the "stop feeding the backend
> early" logic, 2011-05-31).

Yup, I think so.  Back then I think our assumptions are that the
user knows better than giving complex diffcore requests like
find-copies-harder only to discard the results with --quiet, and the
patch started this thread helps other users, which is good ;-).