Re: [PATCH 1/4] Documentation/gitignore: "foo/" patterns match directories, not files under them

> 2011/11/7 Jonathan Nieder <jrnieder@gmail.com>:
>> The gitignore(5) manpage says that "foo/" will match a directory foo
>> and paths underneath it.
>
> If git ignores a directory, then it essentially ignores all paths
> underneath it, doesn't it?
>
>> But that is completely false: as Johannes
>> Sixt likes to remind us, patterns with a trailing '/' match the named
>> directory, not files under that directory.  For example, the following
>> .gitignore file
>>
>>        /build/
>>        !/build/tests/results
>>
>> does not un-ignore build/tests/results since it was never ignored in
>> the first place; and commands like "git status" will not notice
>> changes to build/tests/results because git doesn't enter the (ignored)
>> build/ directory.
>
> I haven't checked but I think it's because when a directory is
> ignored, git just stops checking further ignore rules. So "build" _is_
> ignored, too strongly that it does not care if some files may need to
> be un-ignored later on.
>
> I remember the argument was, because ignore rules are distributed
> across .gitignore files, we would need to go into ignored directories
> for collecting potential un-ignore rules (for example "!results" on
> build/tests/.gitignore) and that just does not make much sense because
> we always have to go into ignored directories.
>
> But in your example, where we know we have negated rules, we should
> follow the rules and ignore all but build/tests/results.
>
>> Correct the manual to just say that "foo/" matches the directory
>> "foo", and make the wording a little clearer in other ways while at
>> it.
>
> I haven't not read the next patches, maybe you have mentioned this
> already. We should make clear that git does not look for negated rules
> once a directory is ignored.
>
> Your example however demonstrates a bug that should be fixed in my
> opinion. So maybe one or two lines under BUGS section.
>
>> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
>> ---
>>  Documentation/gitignore.txt |   14 ++++++++------
>>  1 files changed, 8 insertions(+), 6 deletions(-)
>>
>> diff --git a/Documentation/gitignore.txt b/Documentation/gitignore.txt
>> index 2e7328b8..5b070bf0 100644
>> --- a/Documentation/gitignore.txt
>> +++ b/Documentation/gitignore.txt
>> @@ -72,12 +72,14 @@ PATTERN FORMAT
>>    included again.  If a negated pattern matches, this will
>>    override lower precedence patterns sources.
>>
>> - - If the pattern ends with a slash, it is removed for the
>> -   purpose of the following description, but it would only find
>> -   a match with a directory.  In other words, `foo/` will match a
>> -   directory `foo` and paths underneath it, but will not match a
>> -   regular file or a symbolic link `foo` (this is consistent
>> -   with the way how pathspec works in general in git).
>> + - If the pattern ends with a slash, it will only match
>> +   directories.  In other words, `foo/` will match a
>> +   directory `foo` but will not match a regular file or a
>> +   symbolic link `foo` (this is consistent with the way
>> +   pathspecs work in general in git).
>
> Looks good.

>> ++
>> +The trailing slash is removed before applying the remaining
>> +rules.
>
> Why does the trailing slash of a rule affect the remaining rules?