diff --cached --no-ext-diff --find-copies-harder --quiet exits with wrong status code
- From
D. Ben Knoble <ben.knoble@gmail.com>
- Date
- Nov 8, 2025, 19:05 UTC
- Message-ID
- <CALnO6CBsj+aMvHJoUQ+LHAtXhcFhQeH8AuHyrX+rumur6MQQog@mail.gmail.com>
AFAICT, you need all of the mentioned options to trigger the bug. Allowing ext-diff works fine, I don't think it's triggered in non-cached diffs, and I've never seen it without --find-copies-harder. Notably, s/quiet/exit-code works just fine.
Here's a repro from git.git:
cp git{,1}.c
git add git1.c
git diff --cached --no-ext-diff --quiet --find-copies-harder &&
echo 'this should exit 1!'(And of course, ^quiet^exit-code if your shell supports it yields a different outcome)
Context: my distro applies a patch that allows diff.renames=copies-harder. In a repo with that turned on, git-prompt.sh stopped showing some staged changes. Turns out it runs git diff with all these flags (less --find-copies-harder, which is enabled by the config option). I _have_ confirmed this bug exists in unpatched Git, however.
Some rough debugging notes: when entering diffcore_std (or diffcore_rename_extended's cleanup loop): - for exit-code, diff_queued_diff.nr matches "git ls-files :/ | wc -l" - for quiet, it's just 1 (the first file listed by git ls-files :/, AFAICT) The only other obvious difference I spotted is that the "quick" flag is turned on for quiet, which makes sense.
I tried to figure out who builds the queue, and it looks like it's diff_cache -> unpack_trees -> ..., where at some point for exit-code we _keep_ queuing files, but for quiet we don't.
I also saw diff_cache tweaks opts.diff_index_cached based on --find-copies-harder, but I haven't looked further to see how that affects things or what the interaction with ext-diff is.
Help welcome, thanks.
-- D. Ben Knoble