Re: [PATCH v2 10/14] dir.c: unify is_excluded and is_path_excluded APIs

Karsten Blees [off-list ref] writes:

is_excluded doesn't handle ignored directories, results for paths within
ignored directories are incorrect. This is probably based on the premise
that recursive directory scans should stop at ignored directories,...

Correct.  Long time ago, we used to have strange rules in a case
like this:

	.gitignore has "d/" to exclude it;
        d/.gitignore says "!f" to cause d/f included.

and when you ask about d/f, we would say "d/ is ignored, so we
wouldn't even bother checking and declare it ignored", while asked
about "f" from within "d/" by first chdir'ing to it, we said "the
fact that you are inside d/ alone means you are interested in
looking at its contents, and checking d/.gitignore tells us that you
are interested in f". "recursion stops at ignored paths" mattered
back then.

I think we consistently honors higher level .gitignore files these
days.

Teach is_excluded / prep_exclude about ignored directories: whenever
entering a new directory, first check if the entire directory is excluded.
Remember the excluded state in dir_struct. Don't traverse into already
ignored directories (i.e. don't read irrelevant .gitignore files).
...
Here's some performance data from the linux and WebKit repos (best of 10
runs on a Debian Linux on SSD, core.preloadIndex=true):

       | ls-files -ci   |    status      | status --ignored
       | linux | WebKit | linux | WebKit | linux | WebKit
-------+-------+--------+-------+--------+-------+---------
before | 0.506 |  6.539 | 0.212 |  1.555 | 0.323 |  2.541
after  | 0.080 |  1.191 | 0.218 |  1.583 | 0.321 |  2.579
gain   | 6.325 |  5.490 | 0.972 |  0.982 | 1.006 |  0.985

Nice.