On 21/11/2021 00:46, Junio C Hamano wrote: > Chris Torek <chris.torek@xxxxxxxxx> writes: > >> ... So the standard >> explanation -- at least, the one I use -- is this: >> >> * 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. >> >> This works, but skips over files that are in the index and are in >> a directory that won't be read. So I add one last rule, which is > All of the above is sensible. If you deal with a path that is in > the index upfront, you can simplify the later rules somewhat, I > would think. I.e. add a first rule before everything else that > says: > > * A file in the index is not ignored. Everything below is about a > path not in the index. > > Then your third rule can lose "Unless...", and you do not have to > add one last rule outside the bulleted list, either. > > ;-) > Perhaps, the clarifications are an opportunity to improve the documentation, should the Danial think that the explanation would have helped. The 'ignore' matching rules does appear to show up quite often on the list. Any thoughts, Danial? Philip
