I meant to reply with some info about how I discovered this and just
realized I forgot.  Anyhow I don't think it'll change how yall
prioritize.

I was reviewing a change to swap grep for ripgrep, and was trying to
understand why we got different results with ripgrep with and without
--no-ignore.  Hence, I was testing some of the files that showed up as
differences with git check-ignore - which didn't really answer the
question either.  So I ended up using git check-ignore -v and
inspecting exit codes as a way to try to verify my own sanity, trying
to understand how a file could be both ignored but not ignored, hence
stumbling over this bug.  In the end I figured out that the
differences were that my repository had tracked files which matched
.gitignore patterns (which therefore aren't ignored files), and
ripgrep doesn't know what is tracked or not, just what matches
.gitignore patterns.  That fully explained the apparent misbehavior
(afaict ripgrep doesn't call git check-ignore in any way), but along
the way I found this check-ignore edge case.

On Thu, Sep 18, 2025 at 3:19 PM Junio C Hamano [off-list ref] wrote:

Jeff King [off-list ref] writes:

quoted

AFAICT it has been this way since the inception of the code. I haven't
ever used the exit code of check-ignore. I wonder if the current
behavior is actually useful, along the lines of "exit 0 if any output
was shown, and 1 otherwise". That would justify a difference in behavior
between running with "-v" and without. But again, I've never used the
exit code so I'm not sure in what circumstances it would be useful.

I very much agree with your assessment, as my understanding is that
the command is primarily for debugging your .gitignore pattern by
eyeballing the output from it (as opposed to a serious tool to see
if a particular path is or is not ignored), so I am not surprised if
its exit code handling is buggy, and I am not suprirsed at all if
nobody has even noticed it is buggy ;-).