Re: [RFC] extending git-ls-files --exclude.

[Junio C Hamano <junkio@cox.net>]

Petr Baudis <pasky@suse.cz> 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.