From: Junio C Hamano Date: Mon, 15 Apr 2013 21:35:36 GMT Subject: Re: [PATCH v2 10/14] dir.c: unify is_excluded and is_path_excluded APIs Message-ID: <7vwqs3pjdj.fsf@alter.siamese.dyndns.org> In-Reply-To: <516C510E.5000606@gmail.com> Karsten Blees 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.