{"thread":{"id":"38481","subject":"Relative paths don't work in .gitignore as would be expected.","startedAt":"2015-02-01T22:51:17Z","lastAt":"2015-02-03T20:11:37Z","messageCount":5,"participants":["/#!/JoePea","Stefan Beller","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"255498","messageId":"CAKU1PAWMh_3x9OoFmXG4+5b=7PRckC47k-MAq++SXahxAP5V7g@mail.gmail.com","threadId":"38481","inReplyTo":null,"subject":"Relative paths don't work in .gitignore as would be expected.","fromName":"/#!/JoePea","fromEmail":"trusktr@gmail.com","sentAt":"2015-02-01T22:51:17Z","receivedAt":"2015-02-01T22:51:17Z","isPatch":false,"sender":{"key":"trusktr@gmail.com","avatar":"https://gravatar.com/avatar/4fd85be8f7e2889358f1d5023b1afc7ece0938f7e9acb4e6e5fea5fb6e17efee?d=mp&s=160"},"body":"I have this in my .gitignore:\n\n ./*.js\n\nI would expect that to cause git to ignore .js files in the same\nfolder as .gitignore, but it doesn't do anything. However, this works:\n\n /*.js\n\nI'm not sure what this actually means because a leading slash is the\nroot of some filesystem, and we're not in the root, nor do gitignore\nfiles always exist in the root of a git repo. Being able to have\n\n ./*.js\n\nin .gitignore would make much sense.\n\n/#!/JoePea\n"},{"id":"255503","messageId":"54CF11CA.6000308@gmail.com","threadId":"38481","inReplyTo":"CAKU1PAWMh_3x9OoFmXG4+5b=7PRckC47k-MAq++SXahxAP5V7g@mail.gmail.com","subject":"Re: Relative paths don't work in .gitignore as would be expected.","fromName":"Stefan Beller","fromEmail":"stefanbeller@gmail.com","sentAt":"2015-02-02T05:57:30Z","receivedAt":"2015-02-02T05:57:30Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On 01.02.2015 14:51, /#!/JoePea wrote:\n> I have this in my .gitignore:\n> \n> ./*.js\n> \n> I would expect that to cause git to ignore .js files in the same\n> folder as .gitignore, but it doesn't do anything. However, this works:\n> \n> /*.js\n> \n> I'm not sure what this actually means because a leading slash is the\n> root of some filesystem, \n\nThat's true, though you'd never (barely?) git version control an entire\nfile system?\n\n\nA trailing \"/**\" matches everything inside. For example, \"abc/**\"\nmatches all files inside directory \"abc\", relative to the location\nof the .gitignore file, with infinite depth.\n(from man gitignore, though reading that and not finding a './' it may\nneed improvement\n"},{"id":"255531","messageId":"xmqqsieot999.fsf@gitster.dls.corp.google.com","threadId":"38481","inReplyTo":"54CF11CA.6000308@gmail.com","subject":"Re: Relative paths don't work in .gitignore as would be expected.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-02-02T19:15:46Z","receivedAt":"2015-02-02T19:15:46Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Stefan Beller writes:\n\n> On 01.02.2015 14:51, /#!/JoePea wrote:\n>> I have this in my .gitignore:\n>> \n>> ./*.js\n>> \n>> I would expect that to cause git to ignore .js files in the same\n>> folder as .gitignore, but it doesn't do anything. However, this works:\n>> \n>> /*.js\n>> \n>> I'm not sure what this actually means because a leading slash is the\n>> root of some filesystem, \n\nIsn't gitignore(5) documentation reasonably clear?\n\n - If the pattern ends with a slash, it is removed for the purpose\n of the following description, but it would only find a match with\n a directory. In other words, foo/ will match a directory foo and\n paths underneath it, but will not match a regular file or a\n symbolic link foo (this is consistent with the way how pathspec\n works in general in Git).\n\n - If the pattern does not contain a slash /, Git treats it as a\n shell glob pattern and checks for a match against the pathname\n relative to the location of the .gitignore file (relative to the\n toplevel of the work tree if not from a .gitignore file).\n\n - A leading slash matches the beginning of the pathname. For\n example, \"/*.c\" matches \"cat-file.c\" but not \"mozilla-sha1/sha1.c\".\n\n> That's true, though you'd never (barely?) git version control an entire\n> file system?\n\nWhen you have the entire file system under /.git, \"/var/\" still\nwould be the right way to spell a pattern to match only a directory\n(because of the trailing '/') whose name matches 'var' and lives in\nthe root level of the filesystem (because of the leading '/' anchors\nthe pattern to the same level as the file the pattern appears in,\ni.e. /.gitignore) and no other place.\n\n> (from man gitignore, though reading that and not finding a './' it may\n> need improvement\n\nWe do not allow relative pathname traversal with \".\" or \"..\", do we?\n\nI would be very hesitant to special case \"./*.js\" to mean \"*.js\nfiles in the same directory as .gitignore appears\", as I think it\nrisks intelligent readers to infer \"../foo/*.js\" or \"../*.js\" would\ntake effect, when placed in \"bar/.gitignore\". A design that spreads\nan incorrect assumption/expectation is not a good one, I would have\nto say.\n"},{"id":"255556","messageId":"CALbm-Ea7X3dDrMUw0sDhWf0sg+zs7oRUkRD+aPzD9fHqB=ZuWQ@mail.gmail.com","threadId":"38481","inReplyTo":"xmqqsieot999.fsf@gitster.dls.corp.google.com","subject":"Re: Relative paths don't work in .gitignore as would be expected.","fromName":"Stefan Beller","fromEmail":"stefanbeller@gmail.com","sentAt":"2015-02-03T02:18:27Z","receivedAt":"2015-02-03T02:18:27Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"2015-02-02 11:15 GMT-08:00 Junio C Hamano :\n> Stefan Beller writes:\n>\n>> On 01.02.2015 14:51, /#!/JoePea wrote:\n>>> I have this in my .gitignore:\n>>>\n>>> ./*.js\n>>>\n>>> I would expect that to cause git to ignore .js files in the same\n>>> folder as .gitignore, but it doesn't do anything. However, this works:\n>>>\n>>> /*.js\n>>>\n>>> I'm not sure what this actually means because a leading slash is the\n>>> root of some filesystem,\n>\n> Isn't gitignore(5) documentation reasonably clear?\n>\n> - If the pattern ends with a slash, it is removed for the purpose\n> of the following description, but it would only find a match with\n> a directory. In other words, foo/ will match a directory foo and\n> paths underneath it, but will not match a regular file or a\n> symbolic link foo (this is consistent with the way how pathspec\n> works in general in Git).\n>\n> - If the pattern does not contain a slash /, Git treats it as a\n> shell glob pattern and checks for a match against the pathname\n> relative to the location of the .gitignore file (relative to the\n> toplevel of the work tree if not from a .gitignore file).\n>\n> - A leading slash matches the beginning of the pathname. For\n> example, \"/*.c\" matches \"cat-file.c\" but not \"mozilla-sha1/sha1.c\".\n>\n>> That's true, though you'd never (barely?) git version control an entire\n>> file system?\n>\n> When you have the entire file system under /.git, \"/var/\" still\n> would be the right way to spell a pattern to match only a directory\n> (because of the trailing '/') whose name matches 'var' and lives in\n> the root level of the filesystem (because of the leading '/' anchors\n> the pattern to the same level as the file the pattern appears in,\n> i.e. /.gitignore) and no other place.\n\nOk, that's true. So when I started diving into the wonderful world of\nunix like operating system, one of the first things I was taught is\n\"/\" starts an absolute path, while \"./foo\" or just \"foo\" starts a relative\npath. And this stuck with me. Now I realize git treats the repository\nroot literally as the root and hence absolute paths starting with \"/\"\nmake totally sense inside git as the world stops for git outside its\nwork directory.\n\n>\n>> (from man gitignore, though reading that and not finding a './' it may\n>> need improvement\n>\n> We do not allow relative pathname traversal with \".\" or \"..\", do we?\n\nBecause we don't have to. It's always relative to the .gitignore file\n(foo/.gitignore can talk about bar/ and still mean foo/bar), so we don't\nneed to express the relativity in any special way.\n\n>\n> I would be very hesitant to special case \"./*.js\" to mean \"*.js\n> files in the same directory as .gitignore appears\", as I think it\n> risks intelligent readers to infer \"../foo/*.js\" or \"../*.js\" would\n> take effect, when placed in \"bar/.gitignore\". A design that spreads\n> an incorrect assumption/expectation is not a good one, I would have\n> to say.\n>\n\nI did not say I'd change the behavior of the ignore rules. I rather meant\nto say the documentation could be filled with examples for common\npatterns.\n\nThat way you'd not be required to read all the rules and *think* about\nthem, but rather can just copy/paste and hope it works. ;)\n\nSorry if this sounded otherwise.\n"},{"id":"255582","messageId":"xmqqtwz2rc06.fsf@gitster.dls.corp.google.com","threadId":"38481","inReplyTo":"CALbm-Ea7X3dDrMUw0sDhWf0sg+zs7oRUkRD+aPzD9fHqB=ZuWQ@mail.gmail.com","subject":"Re: Relative paths don't work in .gitignore as would be expected.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-02-03T20:11:37Z","receivedAt":"2015-02-03T20:11:37Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Stefan Beller writes:\n\n> 2015-02-02 11:15 GMT-08:00 Junio C Hamano :\n>\n>> Isn't gitignore(5) documentation reasonably clear?\n>> ...\n>> - A leading slash matches the beginning of the pathname. For\n>> example, \"/*.c\" matches \"cat-file.c\" but not \"mozilla-sha1/sha1.c\".\n>>\n>>> That's true, though you'd never (barely?) git version control an entire\n>>> file system?\n>>\n>> When you have the entire file system under /.git, \"/var/\" still\n>> would be the right way to spell a pattern to match ...\n>> ... and lives in the root level of the filesystem (because of the\n>> leading '/' anchors\n>> the pattern to the same level as the file the pattern appears in,\n>> i.e. /.gitignore) and no other place.\n>\n> ... Now I realize git treats the repository\n> root literally as the root and hence absolute paths starting with \"/\"\n> make totally sense inside git as the world stops for git outside its\n> work directory.\n\nOnly when the pattern appears in .gitignore at the top-level of the\nproject, you can say: \"/*.js\" matches files with \".js\" suffix at the\nroot level of the project because '/' means 'root'.\n\nBut that explanation breaks down for \"t/.gitignore\" that has entries\nlike \"/.prove\". It is not excluding \".prove\" at the top-level of\nthe project. It is excluding those that appear at the same level as\nthat ignore file in question lives in, i.e. the \"t/\" directory. It\nexcludes \"t/.prove\", it excludes neither \".prove\" at the top-level\nnor \"t/tt/ttt/.prove\".\n\nIn hindsight, using '/' prefix as a way to anchor the patter to the\nsame directory the .gitignore file appears in was suboptimal,\nexactly because it would invite the above reaction. But I do not\nknow if using \"./\" as the prefix to denote the same thing would have\nbeen better.\n"}]}