A StackOverflow user posted a question about how to reliably check whether a file would be ignored by "git add" and expected "git check-ignore" to return results that matched git add's behavior. It turns out that it doesn't. If there is a negation rule, we end up returning that exclude and printing it and exiting with 0 (there are some ignored files) even though the file has been marked to not be ignored. Is the expected behavior of "git check-ignore" to return 0 even if the file is not ignore when a negation is present? >>>> git init . echo 'foo/*' > .gitignore echo '!foo/bar' > .gitignore mkdir foo touch foo/bar git check-ignore foo/bar <<<< I expect the last command to return 1 (no files are ignored), but it doesn't. The StackOverflow user had the same expectation, and imagine others do as well. OTOH, it looks like the command is really meant to be a debugging tool--to show me the line in a .gitignore associated with this file, if there is one. In which case, the behavior is correct but the return code description is a bit misleading (0 means the file is ignored, which isn't true here). Thoughts? It seems like this question was asked before several years ago but didn't get a response. Thanks! -John PS The SO question is here: https://stackoverflow.com/questions/45210790/how-to-reliably-check-whether-a-file-is-ignored-by-git
