Stefan Beller <stefanbeller@xxxxxxxxx> writes: > On 01.02.2015 14:51, /#!/JoePea wrote: >> I have this in my .gitignore: >> >> ./*.js >> >> I would expect that to cause git to ignore .js files in the same >> folder as .gitignore, but it doesn't do anything. However, this works: >> >> /*.js >> >> I'm not sure what this actually means because a leading slash is the >> root of some filesystem, Isn't gitignore(5) documentation reasonably clear? - 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). - A leading slash matches the beginning of the pathname. For example, "/*.c" matches "cat-file.c" but not "mozilla-sha1/sha1.c". > That's true, though you'd never (barely?) git version control an entire > file system? When you have the entire file system under /.git, "/var/" still would be the right way to spell a pattern to match only a directory (because of the trailing '/') whose name matches 'var' and lives in the root level of the filesystem (because of the leading '/' anchors the pattern to the same level as the file the pattern appears in, i.e. /.gitignore) and no other place. > (from man gitignore, though reading that and not finding a './' it may > need improvement We do not allow relative pathname traversal with "." or "..", do we? I would be very hesitant to special case "./*.js" to mean "*.js files in the same directory as .gitignore appears", as I think it risks intelligent readers to infer "../foo/*.js" or "../*.js" would take effect, when placed in "bar/.gitignore". A design that spreads an incorrect assumption/expectation is not a good one, I would have to say. -- 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