Re: [PATCH v2] diff: disable rename detection with --quiet
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Nov 10, 2025, 19:13 UTC
- Message-ID
- <xmqqseelzong.fsf@gitster.g>
- In-Reply-To
- <20251110175408.GB76603@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
Show 10 quoted lines
> 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.
Show 6 quoted lines
> 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 ;-).