Junio C Hamano <gitster@xxxxxxxxx> wrote: >Jeremy Faith <jeremy.faith@xxxxxxx> writes: >> git version 2.31.1.362.g311531c9de >> git-check-ignore >> When a negative pattern is the last .gitignore match the -v option causes the exit status to be 0 rather than the expected 1. >> e.g say .gitignore contains one line: !hello >> git check-ignore hello #outputs nothing >> echo $? #shows correct exit status=1 i.e None of the provided paths are ignored. >> but >> git check-ignore -v hello #output is next line >> .gitignore:4:!hello hello >> echo $? #shows wrong exit status=0 i.e. One or more of the provided paths is ignored >Hmph. This is kind of understandable given the history of the >command, which was *not* about programatically ask "is this path >ignored?" question at all. Instead, it was invented to answer this >question: I am puzzled by the fact that Git considers this path is >to be ignored (or "not to be ignored"). Show me which entry in what >exclude file made the final decision to ignore (or "not to ignore") >it to help me debug my ignore file(s). >And the exit code was to signal "yes, I found a relevant entry", >which made sense for the tool's nature as a debugging aid. man git-check-ignore states:- EXIT STATUS ----------- 0:: One or more of the provided paths is ignored. 1:: None of the provided paths are ignored. 128:: A fatal error was encountered. So my change matches what the manual states. >So, I suspect that this is working as designed/intended. I agree >that it is debatable that the way it was designed to work is a good >one, though. I doubt that changing the exit status when -v is added is intended behaviour.
