The attribute patterns (or exclude patterns for that matter) were never designed to name "the current directory". The way to name "everything *in* this directory" has always been to say "*" (the "* text=auto" example in the documentation says it shows how to set the attribute "for all files"). Admittedly the pattern may miss ".*" files.
I have to agree that things like "./" and "." were outside the scope of the design; in some cases undefined behaviour given to such patterns may have made sense but that was mere accident.
If we were to give some defined behaviour to these patterns, updating the "Pattern Format" section of Documentation/gitignore.txt is the first thing to do. The text currently reads like this:
PATTERN FORMAT --------------
- A blank line matches no files, so it can serve as a separator
for readability.
- A line starting with # serves as a comment.
- An optional prefix '!' which 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.
- 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 does not contain a slash '/', git treats it as
a shell glob pattern and checks for a match against the
pathname relative to the location of the `.gitignore` file
(relative to the toplevel of the work tree if not from a
`.gitignore` file).
- 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.
For example, "Documentation/{asterisk}.html" matches
"Documentation/git.html" but not "Documentation/ppc/ppc.html"
or "tools/perf/Documentation/perf.html". - A leading slash matches the beginning of the pathname.
For example, "/{asterisk}.c" matches "cat-file.c" but not
"mozilla-sha1/sha1.c".I think adding the following before the 5th rule ("If the pattern does not contain a slash") would be sufficient:
- If the pattern is a single dot and nothing else, it matches everything
in the current directory.
So "./" in .gitignore or .gitattributes at the toplevel would match all the top-level directories and files but does not apply to the paths contained in the matched directories. "." in .gitignore or .gitattributes at the toplevel would match everything under the sun.
Personally I do not think it is an improvement. You can certainly say "we have one less undefined case and are more consistent", but the downside of that consistency is that it is very confusing and error prone for the end users. Would it be sensible to assume that users would not be surprised if ". text=auto" meant that the attribute applies to every file in the worktree?
