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