2015-02-02 11:15 GMT-08:00 Junio C Hamano <gitster@xxxxxxxxx>: > 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. Ok, that's true. So when I started diving into the wonderful world of unix like operating system, one of the first things I was taught is "/" starts an absolute path, while "./foo" or just "foo" starts a relative path. And this stuck with me. Now I realize git treats the repository root literally as the root and hence absolute paths starting with "/" make totally sense inside git as the world stops for git outside its work directory. > >> (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? Because we don't have to. It's always relative to the .gitignore file (foo/.gitignore can talk about bar/ and still mean foo/bar), so we don't need to express the relativity in any special way. > > 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. > I did not say I'd change the behavior of the ignore rules. I rather meant to say the documentation could be filled with examples for common patterns. That way you'd not be required to read all the rules and *think* about them, but rather can just copy/paste and hope it works. ;) Sorry if this sounded otherwise. -- 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