Petr Baudis <[EMAIL PROTECTED]> writes: > You generally don't say "I never want this ignored, but I want > the rest of that ignored", but "I want that ignored, except > this".
OK. > But more importantly, > > .gitignore: *.txt > Documentation/.gitignore: !*.txt > > will not work, which was the whole _point_ of the exclusion. I agree that this is a bigger issue. My updated proposal is as follows: * We collect --exclude patterns in "command line patterns" list, in the same order as given on the command line. * We collect patterns read from the files specified with --exclude-from in "exclude-from patterns" list, in the same order as given on the command line and the same order patterns appear in the file. * While we descend the directories, files named by EPD flag, if found, are read from top to bottom and concatenated into the "per directory patterns" list. When leaving the directory, the patterns read from that directory's EPD file are popped off. * When checking a file to see if it is excluded, we first look at "exclude-from patterns" list, then "per directory patterns" list, and then "command line patterns list", in that order. The last match wins [*1*]. An example: You have three files in your git source tree and your $HOME: git/.gitignore lists patterns A and B git/Documentation/.gitignore lists patterns C and D git/.git/info/ignore lists patterns E and F $HOME/.gitrc/ignore lists patterns G and H You say: git-ls-files --others \ --exclude=I --exclude=J \ --exclude-from=.git/info/ignore \ --exclude-from=~/.gitrc/ignore \ --exclude-per-directory=.gitignore \ While in git/ directory itself, the following patterns are checked and the last match wins: E F G H A B I J When we descend into git/Documentation, the list of patterns used becomes the following, still the last match wins: E F G H A B C D I J The reason --exclude-from comes first (i.e. having the least say in the outcome) and --exclude comes last (i.e. having the most say) is because the former is to give the overall fallback default, and the latter is the ultimate end user preference. Does this sound reasonable? [Footnote] *1* In real implementation, I would probably scan in reverse from the end and stop at the first match, but that is an implementation detail. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html