From: Junio C Hamano Date: Mon, 10 Nov 2025 19:13:55 GMT Subject: Re: [PATCH v2] diff: disable rename detection with --quiet Message-ID: In-Reply-To: <20251110175408.GB76603@coredump.intra.peff.net> Jeff King 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 ;-).