> * Git opens and reads the working tree directory. For each file > > or directory that is actually present here, Git checks it > > against the ignore rules. Some rules match only directories > > and others match both directories and files. Some rules say > "do ignore" and some say "do not ignore". > * The *last* applicable rule wins. > * If this is a file and the file is ignored, it's ignored. > Unless, that is, it's in the index already, because then it's > tracked and can't be ignored. > * If this is a directory and the directory is ignored, it's > not even opened and read. It's not in the index because > directories are never in the index (at least nominally). > If it is opened and read, the entire set of rules here > apply recursively. > I do think it would be sensible for Git to read a `.gitignore` > > that says: > > * > > !a/b/c > > as meaning: > * > !a/ > !a/b/ > !a/b/c > That is, declaring an un-ignored file within some ignored > directory should automatically imply that we *must* un-ignore the > parents. Thanks, Chris. Yes, it mostly makes sense to me too. I think this will better describe the gitignore behavior. However, checking the indexed files at first may enhance it. In addition to that, there should be an exception about negating patterns. For example, for the "!**/file.txt" pattern, it might be tricky to re-include all possible parents of "file.txt" files. You have to traverse directories to reach files and find out which parents to un-ignore. Any negating pattern with "**" at the beginning or in the middle of the pattern can make trouble. The existing rule which states the file cannot be re-included in case of ignored parents may help to prevent this. Thanks Danial
