"Elijah Newren via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes: > Some sidenotes about possible confusion with dir.c: Thanks for working on untangling this mess ;-) > * "ignored" often refers to an untracked ignore", i.e. a file which is > not tracked which matches one of the ignore/exclusion rules. But you > can also have a "tracked ignore", a tracked file that happens to match > one of the ignore/exclusion rules and which dir.c has to worry about > since "git ls-files -c -i" is supposed to list them. OK. This is to find a pattern in .gitignore that is too broad (i.e. if the path were to be added as a new thing today, it would require "add -f"), right? The combination of "-i -c" does make sense for that purpose. > * The dir code often uses "ignored" and "excluded" interchangeably, > which you need to keep in mind while reading the code. True. In tree .gitignore files are to hold exclude patterns, and per repository personal exclude file is called $GIT_DIR/info/exclude which is confusing. > Sadly, though, > it can get very confusing since ignore rules can have exclusions, as > in the last of the following .gitignore rules: > .gitignore > *~ > *.log > !settings.log > In the last entry above, (pathspec->items[3].magic & PATHSPEC_EXCLUDE) > will be true due the the '!' negating the rule. Someone might refer > to this as "excluded". That one I've never heard of. As far as I am concerned, that is a negative exclude pattern. I do wish we started the project with .gitignore files and $GIT_DIR/info/ignore both of which holds ignore patterns and negative ignore patterns from day one, but the boat sailed long time ago.
