Re: [PATCH] dir.c: allow re-include after a dir is excluded in some cases

[Duy Nguyen <pclouds@gmail.com>]

On Thu, Nov 20, 2014 at 1:48 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Nguyễn Thái Ngọc Duy  <pclouds@gmail.com> writes:
>
>> diff --git a/Documentation/gitignore.txt b/Documentation/gitignore.txt
>> index 09e82c3..0340c44 100644
>> --- a/Documentation/gitignore.txt
>> +++ b/Documentation/gitignore.txt
>> @@ -82,10 +82,9 @@ PATTERN FORMAT
>>
>>   - An optional prefix "`!`" which negates the pattern; any
>>     matching file excluded by a previous pattern will become
>> -   included again. It is not possible to re-include a file if a parent
>> -   directory of that file is excluded. Git doesn't list excluded
>> -   directories for performance reasons, so any patterns on contained
>> -   files have no effect, no matter where they are defined.
>> +   included again.
>> +   It is usually not possible to re-include a file if a parent
>> +   directory of that file is excluded. See NOTES for details.
>>     Put a backslash ("`\`") in front of the first "`!`" for patterns
>>     that begin with a literal "`!`", for example, "`\!important!.txt`".
>>
>> @@ -144,6 +143,12 @@ use 'git update-index {litdd}assume-unchanged'.
>>  To stop tracking a file that is currently tracked, use
>>  'git rm --cached'.
>>
>> +It is usually not possible to re-include a file if a parent directory
>> +of that file is excluded because of performance reasons. However, if
>> +there are negative rules in the same .gitignore file that contains the
>> +rule to ignore a specific directory, and those negative rules contain
>> +a slash, then re-inclusion is possible.
>
> Does that mean "performance reasons" goes out the window???
>
> What trade-off are the users making by choosing to do so?  Is it
> explained in the documentation well enough to allow them to make an
> informed decision?

If they put "!**/foo" there, I think it's obvious for users that all
dirs must be looked at. "!a*/**/foo" may be expected to only look at a
subset of dirs recursively, instead of everything. "!*/def" may be
expected that only one more level of directories are looked at. I
didn't cover the last two cases well and I don't think it'll be easy
to do. Which makes this patch less appealing. (so much for a
not-thoroughly-thought-through quick prototype)

Perhaps I look at it from a wrong angle. If we have a way to say
"these patterns do not apply to directories", then the user can
selectively exclude certain directories and let others through. It
would give the user more control and make the travelling cost more
apparent (assuming we mention somewhere that the more dirs we examine,
the longer it will take).
-- 
Duy