On Sun, Jul 23, 2017 at 12:33 PM, Philip Oakley <philipoakley@xxxxxxx> wrote: [snip] >> >>>>>> >> git init . >> echo 'foo/*' > .gitignore >> echo '!foo/bar' > .gitignore > > > Is this missing the >> append to get the full two line .gitignore? > adding in a `cat .gitignore` would help check. Yes, sorry about that. > >> mkdir foo >> touch foo/bar > > I don't think you need these. It's the given pathnames that are checked, not > the file system content. It was there so you could see that `git status` ignores foo/bar (though that wasn't part of the little script). >> git check-ignore foo/bar > > Does this need the `-q` option to set the exit status? No, it's always set. > echo $? # to display the status. Sure. So, to recap the update reproduction recipe would be: >>>> git init . echo 'foo/*' > .gitignore echo '!foo/bar' >> .gitignore mkdir foo touch foo/bar git status # foo/ shows as untracked because bar is present git check-ignore foo/bar echo $? # show the exit status <<<< It seems like it should print "1", but it prints "0". >> 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). > > > Maybe the logic isn't that clear? Maybe it is simply detecting if any one of > the ignore lines is active, and doesn't reset the status for a negation? > > I appear to get the same response as yourself, but I haven't spent much time > on it - I'm clearing a backlog of work at the moment. Correct, it appears that if any line in the ignore matches, then it exits with 0. So it's not that it's ignored, but that there is a matching line in an ignore file somewhere. I can see the logic in this if it's meant to be a debugging tools, especially combined with -v. Simply changing it does affect quite a few tests, but I'm not sure that it was intentional for negation to be treated this way. > I also tried the -v -n options, and if I swap the ignore lines around it > still says line 2 is the one that ignores. > It gets more interesting if two paths are given `foo/bar foo/baz`, to see > which line picks up which pathname (and with the swapped ignore lines). > > Is there a test for this in the test suite? There are several. But line 427, test_expect_success_multi 'nested include', is one that I think is pretty direct about testing this. I imagine what happened is that gitignores used to contain only things you wanted to ignore and when the ability to negate came along the semantics of this was never changed--and possibly for good reason. I'm just wondering if it should change, or if the documentation should be updated to reflect how it actually behaves (the file may not be ignored, but a line is present in a gitignore that affects its status). The behavior is definitely a little unexpected as it stands, given the documentation though. Thanks for taking a look Philip! -John
