Sitaram Chamarty <sitaramc@xxxxxxxxx> writes:
> Please tell me what you think. If you like it, I'll send in
> this patch. If you prefer the previous one, I'll send that
> in.
> ...
> The files containing the patterns have the following format:
>
> - A blank line matches no files, so it can serve as a
> separator for readability.
>
> - A line starting with # serves as a comment.
>
> This is _how_ the patterns match:
>
> - The wildcards (`*` and `?`) do not match slashes, but
> otherwise the patterns are normal shell globs as defined
> by fnmatch(3) with the FNM_PATHNAME flag set.
I had to read this twice and run "man 3 fnmatch" to clear my head.
- In normal shell globs, wildcards '*' and '?' do not match slashes;
- fnmatch(3) with FNM_PATHNAME implements the normal shell globs;
- wildcards do not match slashes in gitignore either.
Given these three, I am very confused why you say "but otherwise". I
would understand it if it were:
The patterns are treated as normal shell globs defined by fnmatch(3) with
FNM_PATHNAME; in other words, the wildcards (`*` and `?`) do not match
slashes.
> - An optional prefix '!' negates the pattern; any matching
> file excluded by a previous pattern will become included
> again. If a negated pattern matches, this will override
> lower precedence patterns sources.
'!' is not part of _how_ the patterns match. It is _what happens_ when a
pattern marked as such matches (meaning, the syntax for a line in
gitignore file is "an optional '!' followed by a pattern").
An optional prefix '!' is not a part of the pattern and it does not
affect the match. When a path matches such a pattern, instead of
being ignored, it is unignored.
It would be good to clarify that '!' is not part of the pattern, as I'd
like to take J6t's patch that says gitattributes uses the same pattern as
gitignore uses.
> This is _what_ the patterns match:
>
> - If the pattern ends with a slash, it matches only
> directories (and their contents), otherwise it matches
> regular files and symlinks also.
Do we want "(and their contents)" here? Once a directory is ignored like
this, none of its contents, including .gitignore file in it, is examined
because we do not even descend into it.
> This is _where_ the patterns match (a trailing slash is
> ignored for these rules):
>
> - If there is a slash at the start or within the pattern,
> it matches paths relative to the .gitignore file in which
> the pattern is found, or to the root of the working tree
> if the pattern is from one of the other pattern sources
> (i.e., `.git/info/exclude`, `core.excludesfile`)
"at the start or within but not at the end of the pattern"?
> - Otherwise, it matches a path at any depth in the tree
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
