Re: [PATCH] Documentation: enhance gitignore whitelist example

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 5, 2011, 21:39 UTC
Message-ID: <7v4o6cml83.fsf@alter.siamese.dyndns.org>
In-Reply-To: <201104052315.54375.j6t@kdbg.org>

Johannes Sixt <j6t@kdbg.org> writes:

Show 9 quoted lines

>> > @@ -87,7 +89,8 @@ PATTERN FORMAT
>> >
>> >   - Otherwise, git treats the pattern as a shell glob suitable
>> >     for consumption by fnmatch(3) with the FNM_PATHNAME flag:
>> > -   wildcards in the pattern will not match a / in the pathname.
>> > +   wildcards in the pattern will not match a / in the pathname,
>> > +   and do not ignore files with a leading . in the pathname.
>
> I don't think this is correct. * matches .gitignore. I tried it.

It is badly phrased to begin with.

It shouldn't say "do not ignore", which is determined by the presense or the lack of the leading '!' before the pattern. The pattern either matches or does not match paths that begin with dot.

I think we pass FNM_PATHNAME but not FNM_PERIOD, so * would match a period hence ".gitignore". What Eric wrote may be correct in the sense that "the pattern matcher does not _ignore_ .gitignore as not matching but catches it with '*'", but as the result the path ends up getting ignored ;-)

> I propose a paragraph like this in the NOTES section:

I think it makes sense to have something like that, but please state it like "to do Y, do X and Z" (optionally followed by "with just X, Y won't happen because..., hence you need to do Z as well"), instead of starting with "you cannot do Y with only X".

IOW, start from a positive and helpful recipe, and then explain why "you cannot do Y with only X" after that.

Show 16 quoted lines

> --- 8< ---
> When a directory is ignored, it is not possible to un-ignore a single file 
> somewhere in the directory using another pattern. E.g., with the patterns
>
> --------------
> /build/
> !/build/tests/results
> --------------
>
> the file "build/tests/results" is still ignored because when a directory is 
> ignored, its contents are never investigated. In a situation where a few 
> exceptions in an otherwise ignored hierarchy are needed, the recommended 
> procedure is to specify to ignore the root of the hierarchy and then to 'git 
> add -f' the exceptional files. Subsequent changes to the files will not be 
> ignored.
> --- 8< ---