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

From: René Scharfe <l.s.r@web.de>
Date: Nov 9, 2025, 18:35 UTC
Message-ID: <916cf3cc-185f-447d-845d-a65eddee4a36@web.de>
In-Reply-To: <CALnO6CC+ke1L7T+dO13B0FSjLyJqihKHKZaa-B4dh9guxk7z0Q@mail.gmail.com>

On 11/9/25 6:34 PM, D. Ben Knoble wrote:

Show 19 quoted lines

> On Sun, Nov 9, 2025 at 11:43 AM René Scharfe <l.s.r@web.de> wrote:
>>
>> This actually fixes the error code when using the options --cached,
>> --find-copies-harder, --no-ext-diff and --quiet together:
>> run_diff_index() indirectly calls diff-lib.c::show_modified(), which
>> queues even non-modified entries using diff_change() because we need
>> them for copy detection.  diff_change() sets flags.has_changes, though,
>> which causes diff_can_quit_early() to declare we're done after seeing
>> only the very first entry -- way too soon.
> 
> This does describe the behavior I saw, but it seems to me that, if we
> have changes, then we ought to be able to quit early for --quiet, no?
> 
> So there's some other knock-on effect that causes quitting early to be
> wrong here, and I'm not exactly sure what it is (other than the diff
> queues being different sizes when we hit relevant parts of
> diffcore_std, though it's the working case that has the larger queue).
> So I'm having a hard time tying this paragraph to the actual issue
> (mostly due to my complete unfamiliarity with the diffing subsystem).

run_diff_index() calls diff-lib.c::diff_cache() to queue up index entries. As mentioned above it only queues up the very first one, no matter if it's a change or not. In Git's repo this would be .cirrus.yml. That's not the end of it, yet, though. It then calls diffcore_std(), which calls diffcore_rename() to remove non-changes from the queue and overwrites flags.has_changes based on whether the queue is empty now.

René