{"thread":{"id":"44381","subject":"Expanding Includes in .gitignore","startedAt":"2016-10-27T00:22:53Z","lastAt":"2016-10-30T12:54:11Z","messageCount":24,"participants":["Aaron Pelly","Stefan Beller","Alexei Lozovsky","Jeff King","Jacob Keller","Junio C Hamano","Duy Nguyen"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"304935","messageId":"80919456-7563-2c16-ba23-ce4fcc2777de@pelly.co","threadId":"44381","inReplyTo":null,"subject":"Expanding Includes in .gitignore","fromName":"Aaron Pelly","fromEmail":"aaron@pelly.co","sentAt":"2016-10-27T00:22:43Z","receivedAt":"2016-10-27T00:22:53Z","isPatch":false,"sender":{"key":"aaron@pelly.co","avatar":null},"body":"I want a feature. It may be a bad-idea(tm). Advice appreciated.\n\nI want git to be able to include, in its gitignore files, sub-files of\nignores or have it understand a directory of ignore files. Or both.\n\nThe use case for this is where I did not write my own rules, but I want\nto keep them updated. https://github.com/github/gitignore is a damn good\nresource, but I want to pull it and include relevant bits project by\nproject and/or system wide. I don't want to have to update many projects\nmanually if that, or any other, repo changes.\n\nA very brief look at dir.c would indicate that a recursive call from\nadd_excludes to itself when it parses some sort of include tag would do\nit within a file. I'm sure it'd be pretty straight forward to hook into\nsomething in dir.c to parse directories too.\n\nI'm thinking something like \". path/to/include/file\" in an ignore file,\nand/or creating .gitignore.d and/or allowing $HOME/.config/git/ignore\nand $GIT_DIR/info/exclude to be directories. Or some sane and consistent\nmixture of these things.\n\nIn the case of a directory the plan would be to add links to files\nstored/sourced elsewhere. This does pose a precedence question which I\nhaven't thought about yet, but probably makes it too hard for the\nlimited value it brings.\n\nThere is also the issue of malicious/accidental recursion which I\nhaven't thought about deeply either.\n\nI would like to know the desirability/practicality/stupidity of such a\nfeature as I believe it is within my skillset to implement it.\n"},{"id":"304941","messageId":"CAGZ79kasr6ubuOm01rLtdK7pfWqriZE1vioLyxAr2G2Hd1xGhg@mail.gmail.com","threadId":"44381","inReplyTo":"80919456-7563-2c16-ba23-ce4fcc2777de@pelly.co","subject":"Re: Expanding Includes in .gitignore","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2016-10-27T02:22:36Z","receivedAt":"2016-10-27T02:22:42Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"> The use case for this is where I did not write my own rules, but I want\n> to keep them updated. https://github.com/github/gitignore is a damn good\n> resource, but I want to pull it and include relevant bits project by\n> project and/or system wide. I don't want to have to update many projects\n> manually if that, or any other, repo changes.\n\n.git/info/exclude could be a (sym)link to an up to date version\nof the gitignore repo as a hack?\n"},{"id":"304957","messageId":"CALhvvbYqeWw+q=TPxTpve6JKoy0URYeWxj2vVOnzrA_g3Z3esA@mail.gmail.com","threadId":"44381","inReplyTo":"80919456-7563-2c16-ba23-ce4fcc2777de@pelly.co","subject":"Re: Expanding Includes in .gitignore","fromName":"Alexei Lozovsky","fromEmail":"a.lozovsky@gmail.com","sentAt":"2016-10-27T08:19:06Z","receivedAt":"2016-10-27T13:57:34Z","isPatch":false,"sender":{"key":"a.lozovsky@gmail.com","avatar":"https://gravatar.com/avatar/8bb8ff5ec366dd64bd8e08f768082934513da367ae047bcb0039292e4ed6bda5?d=mp&s=160"},"body":"> I'm thinking something like \". path/to/include/file\" in an ignore file,\n> and/or creating .gitignore.d and/or allowing $HOME/.config/git/ignore\n> and $GIT_DIR/info/exclude to be directories. Or some sane and consistent\n> mixture of these things.\n\nI think the rc.d-like approach with directories is better as it\ndoes not add new magical filenames (what if I absolutely do need\nto name my directories \". path\", with a space? :) keeping the\nsyntax of gitignores themselves simple, and allowing us to think\nof files as still being separate entities. This can be useful\nfor the following case:\n\n> In the case of a directory the plan would be to add links to files\n> stored/sourced elsewhere. This does pose a precedence question which I\n> haven't thought about yet, but probably makes it too hard for the\n> limited value it brings.\n\nAs I understand, the precedence only matters for negative patterns\n(the ones that start with an exclamation mark, !). For example,\nsuppose you have files 'foo1' and 'foo2'. This .gitignore\n\n    foo*\n    !foo1\n\nwill ignore foo2, but will show foo1. However, if the lines are\nswapped:\n\n    !foo1\n    foo*\n\nthen both foo1 and foo2 will be ignored.\n\nNow, if we consider the case of multiple .gitignore files, it\ncould be unexpected and possibly annoying for negative patterns\nin one file to affect the patterns added by some other files.\nI would find it more conceptually simple to apply individual\n.gitignores one by one, as opposed to parsing them all and\ncreating one giant exclusion rule. (In technical terms, this\nmeans keeping one struct exclude_list for each .gitignore,\nnot merging them all into one single list.)\n\nIn this case there should be no precendence problems as applied\ngitignores only add new ignored files, without un-ignoring\nanything previously ignored by other files.\n\nHowever, if we allow textual inclusion, then it means that we\ncan put a gitignore into our gitignore so that we can unignore\nwhile we ignore, which again brings us the question of whether\nit is actually needed and expected.\n\n> I would like to know the desirability/practicality/stupidity of such a\n> feature as I believe it is within my skillset to implement it.\n\nIn my mind, this feature definitely has utility and it can be\nimplemented in backwards-compatible way, so why not.\n\nHowever, I do not recall any precendent of git using rc.d-like\nconfigs. And some can argue that your goal can be achieved by\ngenerating the .gitignore by some external means and symlinking\nthe result into .git/info/exclude, so this is not Git's problem\nand we should not be overcomplicating things with something as\nsimple as a list exclude patterns. This line of argument also\ncan be used to opposes any textual inclusion as well, because\nit can be expanded into 'why don't we add a Turing-complete\nprogramming language then to specify the patterns to ignore'.\n"},{"id":"304961","messageId":"91d49c7b-2bc7-a872-24c8-25836dea17fb@pelly.co","threadId":"44381","inReplyTo":"CALhvvbYqeWw+q=TPxTpve6JKoy0URYeWxj2vVOnzrA_g3Z3esA@mail.gmail.com","subject":"Re: Expanding Includes in .gitignore","fromName":"Aaron Pelly","fromEmail":"aaron@pelly.co","sentAt":"2016-10-27T10:33:07Z","receivedAt":"2016-10-27T14:34:04Z","isPatch":false,"sender":{"key":"aaron@pelly.co","avatar":null},"body":"On 27/10/16 21:19, Alexei Lozovsky wrote:\n>> I'm thinking something like \". path/to/include/file\" in an ignore file,\n>> and/or creating .gitignore.d and/or allowing $HOME/.config/git/ignore\n>> and $GIT_DIR/info/exclude to be directories. Or some sane and consistent\n>> mixture of these things.\n>\n> I think the rc.d-like approach with directories is better as it\n> does not add new magical filenames (what if I absolutely do need\n> to name my directories \". path\", with a space? :)\n\nYes. Another alternative I thought of was #include path/to/include/file.\nThat'd be backwards compatible, which is a good thing, but would involve\nparsing comments, which obviously could start with #include. Or lines\nlike ^Include /path/file$ In the case of finding an invalid file,\npassing it over and issuing a simple warning should surface any issues\nwith existing gitignores. Anyway, this conversation is why I bring it up\non the list.\n\nComing back to this, maybe :(include)/path/file might be more git-like\n\n>> In the case of a directory the plan would be to add links to files\n>> stored/sourced elsewhere. This does pose a precedence question which I\n>> haven't thought about yet, but probably makes it too hard for the\n>> limited value it brings.\n>\n> Now, if we consider the case of multiple .gitignore files, it\n> could be unexpected and possibly annoying for negative patterns\n> in one file to affect the patterns added by some other files.\n\nThat is a concern. It is non obvious; the worst kind of annoying.\n\n> I would find it more conceptually simple to apply individual\n> .gitignores one by one, as opposed to parsing them all and\n> creating one giant exclusion rule. (In technical terms, this\n> means keeping one struct exclude_list for each .gitignore,\n> not merging them all into one single list.)\n\nI agree. I haven't looked, but that sounds like touching significantly\nmore code though. Actually, thinking about it for 20 seconds more, it\nshouldn't be too hard, should it?\n\n> In this case there should be no precendence problems as applied\n> gitignores only add new ignored files, without un-ignoring\n> anything previously ignored by other files.\n\nAgain, I haven't looked yet, but there is still an issue of precedence\nwith other gitignore files in $HOME and the repo.\n\n> However, if we allow textual inclusion, then it means that we\n> can put a gitignore into our gitignore so that we can unignore\n> while we ignore, which again brings us the question of whether\n> it is actually needed and expected.\n\nGah! Yes. One way or the other.\n\n>> I would like to know the desirability/practicality/stupidity of such a\n>> feature as I believe it is within my skillset to implement it.\n>\n> However, I do not recall any precendent of git using rc.d-like\n> configs.\n\nMany things have adopted this technique recently. Well, the last 15\nyears. It is common, understood, and fairly simple. I see no issue with it.\n\n> And some can argue that your goal can be achieved by\n> generating the .gitignore by some external means and symlinking\n> the result into .git/info/exclude, so this is not Git's problem\n> and we should not be overcomplicating things with something as\n> simple as a list exclude patterns. This line of argument also\n> can be used to opposes any textual inclusion as well, because\n> it can be expanded into 'why don't we add a Turing-complete\n> programming language then to specify the patterns to ignore'.\n\nI know. Another reason to bring the idea to the list. I sort of have\nthis attitude myself. My main objection to it is that I can't think of a\nhook to automate it with.\n\nBut: What about some kind of :(exec) that executes a script and returns\na gitignore file? You write the script; you're responsible. And the\nbehaviour is obvious. I haven't thought that through. It just came to me\nthen, and might present security issues, but could greatly simplify things.\n\n\n\n\n\n"},{"id":"304963","messageId":"0cf156b2-8fc1-2eb7-e26c-f11f59eec4e2@pelly.co","threadId":"44381","inReplyTo":"CAGZ79kasr6ubuOm01rLtdK7pfWqriZE1vioLyxAr2G2Hd1xGhg@mail.gmail.com","subject":"Re: Expanding Includes in .gitignore","fromName":"Aaron Pelly","fromEmail":"aaron@pelly.co","sentAt":"2016-10-27T09:51:38Z","receivedAt":"2016-10-27T14:49:49Z","isPatch":false,"sender":{"key":"aaron@pelly.co","avatar":null},"body":"On 27/10/16 15:22, Stefan Beller wrote:\n>> The use case for this is where I did not write my own rules, but I want\n>> to keep them updated. https://github.com/github/gitignore is a damn good\n>> resource, but I want to pull it and include relevant bits project by\n>> project and/or system wide. I don't want to have to update many projects\n>> manually if that, or any other, repo changes.\n>\n> .git/info/exclude could be a (sym)link to an up to date version\n> of the gitignore repo as a hack?\n>\n\nUsing links isn't a bad idea, but you still end up at some stage\ncombining the contents of several files that already exist. Well, in my\nexample, anyway.\n\nI accept that I'm being pretty trivial, and once it's set up there's\nnever any pressing need to change anything, but it still irks me.\n\nEven with a linked .gitignore, or .git/info/exclude there will be\nsections that are project, language, editor, machine, whatever,\nspecific. So I still need to copy stuff from one file to another by\nhand. By allowing includes, I only have to have a link to each file\ndescribing the data types for each component of the environment.\n\nAnd they are community maintained, so I don't have to google every time\nI try a new editor.\n\nnote to self: reply-to isn't the list.\n"},{"id":"304964","messageId":"20161027105026.e752znq5jv5a6xea@sigill.intra.peff.net","threadId":"44381","inReplyTo":"80919456-7563-2c16-ba23-ce4fcc2777de@pelly.co","subject":"Re: Expanding Includes in .gitignore","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-10-27T10:50:27Z","receivedAt":"2016-10-27T14:52:41Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Oct 27, 2016 at 01:22:43PM +1300, Aaron Pelly wrote:\n\n> The use case for this is where I did not write my own rules, but I want\n> to keep them updated. https://github.com/github/gitignore is a damn good\n> resource, but I want to pull it and include relevant bits project by\n> project and/or system wide. I don't want to have to update many projects\n> manually if that, or any other, repo changes.\n\nThat seems like a reasonable thing to want.\n\n> A very brief look at dir.c would indicate that a recursive call from\n> add_excludes to itself when it parses some sort of include tag would do\n> it within a file. I'm sure it'd be pretty straight forward to hook into\n> something in dir.c to parse directories too.\n> \n> I'm thinking something like \". path/to/include/file\" in an ignore file,\n> and/or creating .gitignore.d and/or allowing $HOME/.config/git/ignore\n> and $GIT_DIR/info/exclude to be directories. Or some sane and consistent\n> mixture of these things.\n\nI'd shy away from an actual include directive, as it raises a lot of\ncomplications:\n\n  - as you noted, cycles in the include graph need to be detected and\n    broken\n\n  - we parse possibly-hostile .gitignore files from cloned repositories.\n    What happens when I include ask to include /etc/passwd? Probably\n    nothing, but there are setups where it might matter (e.g., something\n    like Travis that auto-builds untrusted repositories, and you could\n    potentially leak the contents of files via error messages). It's\n    nice to avoid the issue entirely.\n\n  - finding a backwards-compatible syntax\n\nWhereas letting any of the user- or repo-level exclude files be a\ndirectory, and simply reading all of the files inside, seems simple and\nobvious. If you go that route, it probably makes sense to teach\ngitattributes the same trick.\n\n> In the case of a directory the plan would be to add links to files\n> stored/sourced elsewhere. This does pose a precedence question which I\n> haven't thought about yet, but probably makes it too hard for the\n> limited value it brings.\n\nI think the normal behavior in such \"foo.d\" directory is to just sort\nthe contents lexically and read them in order, as if they were all\nconcatenated together, and with no recursion. I.e., behave \"as if\" the\nuser had run \"cat $dir/*\".\n\nThat lets you handle precedence via the filenames (or symlink names). It\ncan't handle all cases (some items in \"00foo\" want precedence over \"01bar\"\nand vice versa), but I don't think there's an easy solution. That's a\ngood sign that one or more of the files should be broken up.\n\n-Peff\n"},{"id":"304983","messageId":"CA+P7+xqmVM-bEc7sZcn+p3qhFUUJvC+rko7CYu+KgyTAeiOifw@mail.gmail.com","threadId":"44381","inReplyTo":"20161027105026.e752znq5jv5a6xea@sigill.intra.peff.net","subject":"Re: Expanding Includes in .gitignore","fromName":"Jacob Keller","fromEmail":"jacob.keller@gmail.com","sentAt":"2016-10-27T19:48:34Z","receivedAt":"2016-10-27T19:49:04Z","isPatch":false,"sender":{"key":"jacob.keller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/874719?v=4"},"body":"On Thu, Oct 27, 2016 at 3:50 AM, Jeff King <peff@peff.net> wrote:\n> On Thu, Oct 27, 2016 at 01:22:43PM +1300, Aaron Pelly wrote:\n>\n>> The use case for this is where I did not write my own rules, but I want\n>> to keep them updated. https://github.com/github/gitignore is a damn good\n>> resource, but I want to pull it and include relevant bits project by\n>> project and/or system wide. I don't want to have to update many projects\n>> manually if that, or any other, repo changes.\n>\n> That seems like a reasonable thing to want.\n>\n\nAgreed, this seems useful to me.\n\n>> A very brief look at dir.c would indicate that a recursive call from\n>> add_excludes to itself when it parses some sort of include tag would do\n>> it within a file. I'm sure it'd be pretty straight forward to hook into\n>> something in dir.c to parse directories too.\n>>\n>> I'm thinking something like \". path/to/include/file\" in an ignore file,\n>> and/or creating .gitignore.d and/or allowing $HOME/.config/git/ignore\n>> and $GIT_DIR/info/exclude to be directories. Or some sane and consistent\n>> mixture of these things.\n>\n> I'd shy away from an actual include directive, as it raises a lot of\n> complications:\n>\n>   - as you noted, cycles in the include graph need to be detected and\n>     broken\n>\n>   - we parse possibly-hostile .gitignore files from cloned repositories.\n>     What happens when I include ask to include /etc/passwd? Probably\n>     nothing, but there are setups where it might matter (e.g., something\n>     like Travis that auto-builds untrusted repositories, and you could\n>     potentially leak the contents of files via error messages). It's\n>     nice to avoid the issue entirely.\n>\n>   - finding a backwards-compatible syntax\n>\n> Whereas letting any of the user- or repo-level exclude files be a\n> directory, and simply reading all of the files inside, seems simple and\n> obvious. If you go that route, it probably makes sense to teach\n> gitattributes the same trick.\n\nYep that would be easier and simpler.\n\n>\n>> In the case of a directory the plan would be to add links to files\n>> stored/sourced elsewhere. This does pose a precedence question which I\n>> haven't thought about yet, but probably makes it too hard for the\n>> limited value it brings.\n>\n> I think the normal behavior in such \"foo.d\" directory is to just sort\n> the contents lexically and read them in order, as if they were all\n> concatenated together, and with no recursion. I.e., behave \"as if\" the\n> user had run \"cat $dir/*\".\n\nYea, this is the normal behavior, and the user is expected to order\ntheir files lexically such as \"00-name\", \"50-name\" and so on. Pretty\ntraditional for a lot of newer configurations.\n\n>\n> That lets you handle precedence via the filenames (or symlink names). It\n> can't handle all cases (some items in \"00foo\" want precedence over \"01bar\"\n> and vice versa), but I don't think there's an easy solution. That's a\n> good sign that one or more of the files should be broken up.\n>\n\nYea if you have these inter-dependent relationships it can't be\nexpressed, but then neither can it really be expressed in the simple\n\"include\" case above.\n\nI would strongly prefer rc.d style directories either with a \"if the\n.gitignore is a directory treat it like rc.d\" or even \"add support for\n.gitignore.d as well as .gitignore\"\n\nOne thing to keep in mind would be that we should make sure we can\nhandle the .gitignore being a submodule or a git repository, so that\nusers could just do something like\n\n\"git submodule add <repo> .gitignore and then track git ignore\ncontents from a repository in a nice way.\n\nBy this I mean that the reading of files in .gitignore directory\nshould exclude reading .git or other hidden files in some documented\nmanor so as to avoid problems when linking to a git directory for its\ncontents.\n\nThanks,\nJake\n\n> -Peff\n"},{"id":"304987","messageId":"b20b458c-440d-df09-d2c7-e510ac20492c@pelly.co","threadId":"44381","inReplyTo":"20161027105026.e752znq5jv5a6xea@sigill.intra.peff.net","subject":"Re: Expanding Includes in .gitignore","fromName":"Aaron Pelly","fromEmail":"aaron@pelly.co","sentAt":"2016-10-27T20:28:23Z","receivedAt":"2016-10-27T20:28:34Z","isPatch":false,"sender":{"key":"aaron@pelly.co","avatar":null},"body":"On 27/10/16 23:50, Jeff King wrote:\n> I'd shy away from an actual include directive, as it raises a lot of\n> complications:\n\nI'm leaning that way now too.\n\n>   - we parse possibly-hostile .gitignore files from cloned repositories.\n>     What happens when I include ask to include /etc/passwd? Probably\n>     nothing, but there are setups where it might matter (e.g., something\n>     like Travis that auto-builds untrusted repositories, and you could\n>     potentially leak the contents of files via error messages). It's\n>     nice to avoid the issue entirely.\n\nI understand the issue.\n\nIt's not obvious to me how using a .d solves this problem though.\n\n>   - finding a backwards-compatible syntax\n\nusing .d directories solves this nicely in my opinion\n\n> Whereas letting any of the user- or repo-level exclude files be a\n> directory, and simply reading all of the files inside, seems simple and\n> obvious.\n\nApart from backwards compatibility, unless there's something I'm missing.\n\n> If you go that route, it probably makes sense to teach\n> gitattributes the same trick.\n\nUnderstood. I'll keep that in mind.\n\n>> In the case of a directory the plan would be to add links to files\n>> stored/sourced elsewhere. This does pose a precedence question which I\n>> haven't thought about yet, but probably makes it too hard for the\n>> limited value it brings.\n> \n> I think the normal behavior in such \"foo.d\" directory is to just sort\n> the contents lexically and read them in order, as if they were all\n> concatenated together, and with no recursion. I.e., behave \"as if\" the\n> user had run \"cat $dir/*\".\n> \n> That lets you handle precedence via the filenames (or symlink names).\n\nThat was my thinking at first, but I didn't want to bias the discussion.\n\n> It\n> can't handle all cases (some items in \"00foo\" want precedence over \"01bar\"\n> and vice versa), but I don't think there's an easy solution. That's a\n> good sign that one or more of the files should be broken up.\n\nI've been burned by this myself by packages interfering with each other\nin /etc/sysctl.d\n\nCould we put this down to caveat emptor? I think this sorting should be\nintuitive to most people these days, and simple to document and comprehend.\n\n\n\n"},{"id":"304990","messageId":"20161027205508.vqw44zlbnqpj2cvd@sigill.intra.peff.net","threadId":"44381","inReplyTo":"b20b458c-440d-df09-d2c7-e510ac20492c@pelly.co","subject":"Re: Expanding Includes in .gitignore","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-10-27T20:55:08Z","receivedAt":"2016-10-27T20:55:17Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Oct 28, 2016 at 09:28:23AM +1300, Aaron Pelly wrote:\n\n> >   - we parse possibly-hostile .gitignore files from cloned repositories.\n> >     What happens when I include ask to include /etc/passwd? Probably\n> >     nothing, but there are setups where it might matter (e.g., something\n> >     like Travis that auto-builds untrusted repositories, and you could\n> >     potentially leak the contents of files via error messages). It's\n> >     nice to avoid the issue entirely.\n> \n> I understand the issue.\n> \n> It's not obvious to me how using a .d solves this problem though.\n\nIt doesn't by itself. But we are worried only about tracked .gitignore\nfiles (recall that even repo-level files in $GIT_DIR/info are generated\nfresh by the clone process, and don't come from the remote). If we apply\nthe feature only to core.excludeFile and $GIT_DIR/info/exclude, those\nare already under the user's control.\n\nIt's true that we could make a similar exception for an \"include\"\nfeature, and respect include directives only in those \"safe\" files.\nSomehow that seems more confusing to me, though, than doing adding the\nfeature at the file level, as it introduces slightly varying syntax\nbetween the locations.\n\n> > Whereas letting any of the user- or repo-level exclude files be a\n> > directory, and simply reading all of the files inside, seems simple and\n> > obvious.\n> \n> Apart from backwards compatibility, unless there's something I'm missing.\n\nI'm not sure what you mean. If we make:\n\n  mkdir .git/info/exclude\n  echo whatever >.git/info/exclude/local\n\nwork, I don't think we have to care about backwards compatibility. That\nwas nonsensical before, and never did anything useful (so somebody might\nhave done it, but we can assume anybody relying on it not to read the\ncontents is crazy).\n\n> > It\n> > can't handle all cases (some items in \"00foo\" want precedence over \"01bar\"\n> > and vice versa), but I don't think there's an easy solution. That's a\n> > good sign that one or more of the files should be broken up.\n> \n> I've been burned by this myself by packages interfering with each other\n> in /etc/sysctl.d\n> \n> Could we put this down to caveat emptor? I think this sorting should be\n> intuitive to most people these days, and simple to document and comprehend.\n\nYeah, I think caveat emptor is fine there. Sorry if I implied otherwise.\n\n-Peff\n"},{"id":"304992","messageId":"067f4a57-2382-07e3-6873-79af78b4a9a1@pelly.co","threadId":"44381","inReplyTo":"CA+P7+xqmVM-bEc7sZcn+p3qhFUUJvC+rko7CYu+KgyTAeiOifw@mail.gmail.com","subject":"Re: Expanding Includes in .gitignore","fromName":"Aaron Pelly","fromEmail":"aaron@pelly.co","sentAt":"2016-10-27T20:59:48Z","receivedAt":"2016-10-27T21:00:00Z","isPatch":false,"sender":{"key":"aaron@pelly.co","avatar":null},"body":"On 28/10/16 08:48, Jacob Keller wrote:\n> I would strongly prefer rc.d style directories either with a \"if the\n> .gitignore is a directory treat it like rc.d\" or even \"add support for\n> .gitignore.d as well as .gitignore\"\n\nI think adding .gitignore.d shouldn't break existing systems, is\nintuitive, and solves my issue.\n\nDoes git know when it is in a repo that is too new to comprehend?\n\nMy current thinking is that anywhere a .gitignore can go, so can a\n.gitignore.d (named appropriately of course.) Any existing .gitignore\nshould take precedence to the result of parsing the directory.\n\nI haven't looked at the implementation of precedence yet, but I'd be\nsurprised if the existing mechanism can't be employed.\n\n> One thing to keep in mind would be that we should make sure we can\n> handle the .gitignore being a submodule or a git repository, so that\n> users could just do something like\n> \n> \"git submodule add <repo> .gitignore and then track git ignore\n> contents from a repository in a nice way.\n> \n> By this I mean that the reading of files in .gitignore directory\n> should exclude reading .git or other hidden files in some documented\n> manor so as to avoid problems when linking to a git directory for its\n> contents.\n\nNice! I like this a lot.\n\n"},{"id":"304993","messageId":"20161027210458.ptzh4y75dkfaixeo@sigill.intra.peff.net","threadId":"44381","inReplyTo":"CA+P7+xqmVM-bEc7sZcn+p3qhFUUJvC+rko7CYu+KgyTAeiOifw@mail.gmail.com","subject":"Re: Expanding Includes in .gitignore","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-10-27T21:04:59Z","receivedAt":"2016-10-27T21:05:05Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Oct 27, 2016 at 12:48:34PM -0700, Jacob Keller wrote:\n\n> > I think the normal behavior in such \"foo.d\" directory is to just sort\n> > the contents lexically and read them in order, as if they were all\n> > concatenated together, and with no recursion. I.e., behave \"as if\" the\n> > user had run \"cat $dir/*\".\n> \n> Yea, this is the normal behavior, and the user is expected to order\n> their files lexically such as \"00-name\", \"50-name\" and so on. Pretty\n> traditional for a lot of newer configurations.\n\nOne thing I will say about this approach is that you can implement it\nwithout any changes in git by doing:\n\n  path=.git/info/exclude\n  cat $path.d/* >$path\n\nand I have seen several config mechanisms basically do that (e.g.,\nDebian packaging for a program that doesn't have its own \".d\" mechanism,\nbut needs to grab config provided by several separate packages).\n\nThe reason to teach that trick to git is convenience; you don't have to\nremember to build the master file from its parts because it's done\ndynamically whenever git needs to look at it.\n\n> One thing to keep in mind would be that we should make sure we can\n> handle the .gitignore being a submodule or a git repository, so that\n> users could just do something like\n\nI'm not convinced this is needed for in-repo .gitignore files. The point\nis that you are pulling together separate files that may be administered\nindependently. But git repositories inherently have a whole-project\nview. I'm not sure that separate files buy you a lot there. And the\ncompatibility issues are more complicated.\n\nI do agree that:\n\n  cd .git/info\n  git clone /my/exclude/repo exclude ;# or exclude.d\n\nshould work; ignoring dotfiles when reading the directory solves that,\nand is a pretty standard solution.\n\n-Peff\n"},{"id":"304994","messageId":"20161027210753.btc7zbndhdocsbwa@sigill.intra.peff.net","threadId":"44381","inReplyTo":"20161027205508.vqw44zlbnqpj2cvd@sigill.intra.peff.net","subject":"Re: Expanding Includes in .gitignore","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-10-27T21:07:53Z","receivedAt":"2016-10-27T21:08:01Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Oct 27, 2016 at 04:55:08PM -0400, Jeff King wrote:\n\n> On Fri, Oct 28, 2016 at 09:28:23AM +1300, Aaron Pelly wrote:\n> \n> > >   - we parse possibly-hostile .gitignore files from cloned repositories.\n> > >     What happens when I include ask to include /etc/passwd? Probably\n> > >     nothing, but there are setups where it might matter (e.g., something\n> > >     like Travis that auto-builds untrusted repositories, and you could\n> > >     potentially leak the contents of files via error messages). It's\n> > >     nice to avoid the issue entirely.\n> > \n> > I understand the issue.\n> > \n> > It's not obvious to me how using a .d solves this problem though.\n> \n> It doesn't by itself. But we are worried only about tracked .gitignore\n> files (recall that even repo-level files in $GIT_DIR/info are generated\n> fresh by the clone process, and don't come from the remote). If we apply\n> the feature only to core.excludeFile and $GIT_DIR/info/exclude, those\n> are already under the user's control.\n> \n> It's true that we could make a similar exception for an \"include\"\n> feature, and respect include directives only in those \"safe\" files.\n> Somehow that seems more confusing to me, though, than doing adding the\n> feature at the file level, as it introduces slightly varying syntax\n> between the locations.\n\nActually, I suppose even a \".gitignore.d\" inside the repo solves that\nproblem, too, because the repository is not specifying paths, only\ncontent (it can specify symlinks outside the repository, but like other\nparts of git, we should be careful not to follow them in that case).\n\nHowever, as I said elsewhere, I'm not convinced this feature is all that\nhelpful for in-repository .gitignore files, and I think it does\nintroduce compatibility complications. People with older git will not\nrespect your .gitignore.d files. Whereas $GIT_DIR/info is purely a local\nmatter.\n\nBut perhaps there is a use case I'm missing.\n\n-Peff\n"},{"id":"304996","messageId":"dc71f67c-e244-c3f7-534a-1d946c2324d0@pelly.co","threadId":"44381","inReplyTo":"20161027210458.ptzh4y75dkfaixeo@sigill.intra.peff.net","subject":"Re: Expanding Includes in .gitignore","fromName":"Aaron Pelly","fromEmail":"aaron@pelly.co","sentAt":"2016-10-27T21:26:25Z","receivedAt":"2016-10-27T21:26:36Z","isPatch":false,"sender":{"key":"aaron@pelly.co","avatar":null},"body":"On 28/10/16 10:04, Jeff King wrote:\n> On Thu, Oct 27, 2016 at 12:48:34PM -0700, Jacob Keller wrote:\n> \n>>> I think the normal behavior in such \"foo.d\" directory is to just sort\n>>> the contents lexically and read them in order, as if they were all\n>>> concatenated together, and with no recursion. I.e., behave \"as if\" the\n>>> user had run \"cat $dir/*\".\n>>\n>> Yea, this is the normal behavior, and the user is expected to order\n>> their files lexically such as \"00-name\", \"50-name\" and so on. Pretty\n>> traditional for a lot of newer configurations.\n> \n> One thing I will say about this approach is that you can implement it\n> without any changes in git by doing:\n> \n>   path=.git/info/exclude\n>   cat $path.d/* >$path\n> \n> and I have seen several config mechanisms basically do that (e.g.,\n> Debian packaging for a program that doesn't have its own \".d\" mechanism,\n> but needs to grab config provided by several separate packages).\n> \n> The reason to teach that trick to git is convenience; you don't have to\n> remember to build the master file from its parts because it's done\n> dynamically whenever git needs to look at it.\n\nPrecisely.\n\n>> One thing to keep in mind would be that we should make sure we can\n>> handle the .gitignore being a submodule or a git repository, so that\n>> users could just do something like\n> \n> I'm not convinced this is needed for in-repo .gitignore files. The point\n> is that you are pulling together separate files that may be administered\n> independently. But git repositories inherently have a whole-project\n> view. I'm not sure that separate files buy you a lot there. And the\n> compatibility issues are more complicated.\n> \n> I do agree that:\n> \n>   cd .git/info\n>   git clone /my/exclude/repo exclude ;# or exclude.d\n> \n> should work; ignoring dotfiles when reading the directory solves that,\n> and is a pretty standard solution.\n\nYou raise a good point about the requirement. I was about to make an\nargument in favour of it, but I argued myself out of an argument. I will\nsay; why have it work in one place and not others?\n\n"},{"id":"304998","messageId":"CA+P7+xrEz7XhZ4fHYUA7gjJtbW8WUEWQhtpAQ+zMC9nVE135iw@mail.gmail.com","threadId":"44381","inReplyTo":"20161027210458.ptzh4y75dkfaixeo@sigill.intra.peff.net","subject":"Re: Expanding Includes in .gitignore","fromName":"Jacob Keller","fromEmail":"jacob.keller@gmail.com","sentAt":"2016-10-27T21:39:43Z","receivedAt":"2016-10-27T21:40:09Z","isPatch":false,"sender":{"key":"jacob.keller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/874719?v=4"},"body":"On Thu, Oct 27, 2016 at 2:04 PM, Jeff King <peff@peff.net> wrote:\n> I'm not convinced this is needed for in-repo .gitignore files. The point\n> is that you are pulling together separate files that may be administered\n> independently. But git repositories inherently have a whole-project\n> view. I'm not sure that separate files buy you a lot there. And the\n> compatibility issues are more complicated.\n>\n\nI had just assumed it would be used everywhere, so I hadn't really\nconsidered whether that was any reason not to. I personally like the\nidea of splitting my git ignores into separate files just so each file\ncan be about one thing, but I guess it's not really a problem either\nway.\n\n> I do agree that:\n>\n>   cd .git/info\n>   git clone /my/exclude/repo exclude ;# or exclude.d\n>\n> should work; ignoring dotfiles when reading the directory solves that,\n> and is a pretty standard solution.\n>\n> -Peff\n"},{"id":"305001","messageId":"60a652f6-864e-bbda-7394-4751c92866b7@pelly.co","threadId":"44381","inReplyTo":"20161027205508.vqw44zlbnqpj2cvd@sigill.intra.peff.net","subject":"Re: Expanding Includes in .gitignore","fromName":"Aaron Pelly","fromEmail":"aaron@pelly.co","sentAt":"2016-10-27T21:55:40Z","receivedAt":"2016-10-27T21:55:51Z","isPatch":false,"sender":{"key":"aaron@pelly.co","avatar":null},"body":"On 28/10/16 09:55, Jeff King wrote:\n> On Fri, Oct 28, 2016 at 09:28:23AM +1300, Aaron Pelly wrote:\n> \n>>>   - we parse possibly-hostile .gitignore files from cloned repositories.\n>>>     What happens when I include ask to include /etc/passwd? Probably\n>>>     nothing, but there are setups where it might matter (e.g., something\n>>>     like Travis that auto-builds untrusted repositories, and you could\n>>>     potentially leak the contents of files via error messages). It's\n>>>     nice to avoid the issue entirely.\n>>\n>> I understand the issue.\n>>\n>> It's not obvious to me how using a .d solves this problem though.\n> \n> It doesn't by itself. But we are worried only about tracked .gitignore\n> files (recall that even repo-level files in $GIT_DIR/info are generated\n> fresh by the clone process, and don't come from the remote). If we apply\n> the feature only to core.excludeFile and $GIT_DIR/info/exclude, those\n> are already under the user's control.\n\nThe things you say make sense from this perspective.\n\nI was hoping to employ this mechanism throughout the git ecosystem.\n\nThinking out loud for a minute:\n\n1) I clone a repo with a hostile ignore file. It includes files from\n/etc/ssl/private or some such. Change. Don't pay attention. Commit.\nPush. Problems.\n\nWhat is the use case for reaching out of the repo in the first place?\n\n2) I fetch a repo with a hostile ignore file. It includes files from\n$GIT_DIR/test-data/ssl/private or some such. Change. Don't pay\nattention. Commit. Push. Problems if my test data comes from production.\n\nIs this mitigated currently?\n\nNot that git should be an enabler, but surely it falls on the user of\nuntrusted software to ensure their own security?\n\n> It's true that we could make a similar exception for an \"include\"\n> feature, and respect include directives only in those \"safe\" files.\n> Somehow that seems more confusing to me, though, than doing adding the\n> feature at the file level, as it introduces slightly varying syntax\n> between the locations.\n\nI'm quickly getting over the include file idea. But yes, that would be\nnon obvious.\n\n>>> Whereas letting any of the user- or repo-level exclude files be a\n>>> directory, and simply reading all of the files inside, seems simple and\n>>> obvious.\n>>\n>> Apart from backwards compatibility, unless there's something I'm missing.\n> \n> I'm not sure what you mean. If we make:\n> \n>   mkdir .git/info/exclude\n>   echo whatever >.git/info/exclude/local\n> \n> work, I don't think we have to care about backwards compatibility. That\n> was nonsensical before, and never did anything useful (so somebody might\n> have done it, but we can assume anybody relying on it not to read the\n> contents is crazy).\n\nSeeing your perspective, now, I can see why you didn't understand me. In\nyour context this makes perfect sense.\n\n"},{"id":"305007","messageId":"91e0f377-ecfd-ab0a-4f4b-8c0f762228aa@pelly.co","threadId":"44381","inReplyTo":"60a652f6-864e-bbda-7394-4751c92866b7@pelly.co","subject":"Re: Expanding Includes in .gitignore","fromName":"Aaron Pelly","fromEmail":"aaron@pelly.co","sentAt":"2016-10-27T22:17:26Z","receivedAt":"2016-10-27T22:17:46Z","isPatch":false,"sender":{"key":"aaron@pelly.co","avatar":null},"body":"On 28/10/16 10:55, Aaron Pelly wrote:\n> 2) I fetch a repo with a hostile ignore file. It includes files from\n> $GIT_DIR/test-data/ssl/private or some such. Change. Don't pay\n> attention. Commit. Push. Problems if my test data comes from production.\n> \n> Is this mitigated currently?\n> \n> Not that git should be an enabler, but surely it falls on the user of\n> untrusted software to ensure their own security?\n\nBalls, I meant $GIT_WORK_TREE not $GIT_DIR\n\n"},{"id":"305011","messageId":"ad01f925-dcfd-4b98-6998-73965c72f69f@pelly.co","threadId":"44381","inReplyTo":"20161027210753.btc7zbndhdocsbwa@sigill.intra.peff.net","subject":"Re: Expanding Includes in .gitignore","fromName":"Aaron Pelly","fromEmail":"aaron@pelly.co","sentAt":"2016-10-27T22:30:44Z","receivedAt":"2016-10-27T22:30:55Z","isPatch":false,"sender":{"key":"aaron@pelly.co","avatar":null},"body":"On 28/10/16 10:07, Jeff King wrote:\n> I think it does\n> introduce compatibility complications. People with older git will not\n> respect your .gitignore.d files. Whereas $GIT_DIR/info is purely a local\n> matter.\n\nI know. I don't think it's a serious compatibility issue, but more\nimportant people may disagree, in which case I'll have to review my\nstance. I think the pros of it working everywhere outweigh the cons.\n\nI will say that I am a proponent of consistency and obviousness. I would\nrather this worked the same everywhere or it was a completely novel\ncomponent in $GIT_DIR.\n\nI don't think I like the idea much, but it would be possible to\nmagically generate an ignore file from a directory.\n\n> But perhaps there is a use case I'm missing.\n\nA new repo where the dev tools haven't been standardised yet. New tool,\nnew file. Simple, and somewhat self documenting as a table of contents\nin .gitignore.d\n\n"},{"id":"305025","messageId":"c2b917af-afc6-20de-14a5-3070f92bb243@pelly.co","threadId":"44381","inReplyTo":"20161027210753.btc7zbndhdocsbwa@sigill.intra.peff.net","subject":"Re: Expanding Includes in .gitignore","fromName":"Aaron Pelly","fromEmail":"aaron@pelly.co","sentAt":"2016-10-27T23:07:36Z","receivedAt":"2016-10-27T23:07:46Z","isPatch":false,"sender":{"key":"aaron@pelly.co","avatar":null},"body":"On 28/10/16 10:07, Jeff King wrote:\n> I think it does\n> introduce compatibility complications.\n\nIf this is not a show stopper, I am happy to knock out a short\nfunctional spec. I'll give it some hours before I begin.\n\n"},{"id":"305037","messageId":"xmqqwpgt2ng2.fsf@gitster.mtv.corp.google.com","threadId":"44381","inReplyTo":"20161027210753.btc7zbndhdocsbwa@sigill.intra.peff.net","subject":"Re: Expanding Includes in .gitignore","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-10-28T02:54:05Z","receivedAt":"2016-10-28T02:54:13Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> However, as I said elsewhere, I'm not convinced this feature is all that\n> helpful for in-repository .gitignore files, and I think it does\n> introduce compatibility complications. People with older git will not\n> respect your .gitignore.d files. Whereas $GIT_DIR/info is purely a local\n> matter.\n\nAs I do not see the point of making in-tree .gitignore to a forest\nof .gitignore.d/ at all, compatibility complications is not worth\neven thinking about, I would have to say.\n\nThanks.\n\n\n\n"},{"id":"305046","messageId":"20161028081033.vaolxkofs6b4wfhf@sigill.intra.peff.net","threadId":"44381","inReplyTo":"91e0f377-ecfd-ab0a-4f4b-8c0f762228aa@pelly.co","subject":"Re: Expanding Includes in .gitignore","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-10-28T08:10:33Z","receivedAt":"2016-10-28T08:10:44Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Oct 28, 2016 at 11:17:26AM +1300, Aaron Pelly wrote:\n\n> On 28/10/16 10:55, Aaron Pelly wrote:\n> > 2) I fetch a repo with a hostile ignore file. It includes files from\n> > $GIT_DIR/test-data/ssl/private or some such. Change. Don't pay\n> > attention. Commit. Push. Problems if my test data comes from production.\n> > \n> > Is this mitigated currently?\n> > \n> > Not that git should be an enabler, but surely it falls on the user of\n> > untrusted software to ensure their own security?\n> \n> Balls, I meant $GIT_WORK_TREE not $GIT_DIR\n\nI was going to ask what you meant by \"currently\" here, as we do not yet\nhave an include mechanism, and generally things in the repository are\nfair game. But I guess you mean that there could be untracked files even\ninside the repository.\n\nI'm not too worried about that in general. You have to be careful of a\nlot of things inside the repository, like running \"make\" on malicious\ncode. Adding \"don't stick secret files inside the repository, even\nuntracked\", does seem like another sensible precaution.\n\nThe main thing with malicious repositories is that basic inspection like\n\"git clone $remote && git log\" should not execute arbitrary code, leak\ninformation, etc.\n\n-Peff\n"},{"id":"305050","messageId":"cc23eece-d693-9e40-78fe-3bafe6bcad3a@pelly.co","threadId":"44381","inReplyTo":"xmqqwpgt2ng2.fsf@gitster.mtv.corp.google.com","subject":"Re: Expanding Includes in .gitignore","fromName":"Aaron Pelly","fromEmail":"aaron@pelly.co","sentAt":"2016-10-28T09:32:07Z","receivedAt":"2016-10-28T09:32:28Z","isPatch":false,"sender":{"key":"aaron@pelly.co","avatar":null},"body":"On 28/10/16 15:54, Junio C Hamano wrote:\n> Jeff King <peff@peff.net> writes:\n> \n>> However, as I said elsewhere, I'm not convinced this feature is all that\n>> helpful for in-repository .gitignore files, and I think it does\n>> introduce compatibility complications. People with older git will not\n>> respect your .gitignore.d files. Whereas $GIT_DIR/info is purely a local\n>> matter.\n> \n> As I do not see the point of making in-tree .gitignore to a forest\n> of .gitignore.d/ at all, compatibility complications is not worth\n> even thinking about, I would have to say.\n\nWell; that saves some work. :)\n\nI do not suggesting making this mandatory. I think it adds value and it\nis a common and understood mechanism. But, if it is abhorrent, consider:\n\nThere is precedent for including files in git-config. This could be\nextended to ignore files. The code is not similar, but the concept is. I\ncould live with it.\n\nOr how about a new githook that can intelligently create or return the\ndetails? This would be my least favourite option unless it was\nconfigured in an obvious place.\n\nFinally, if this is a bad-idea, as I asked in the beginning, I will\nconsider the equine expired, cease flagellation and apologise for the noise.\n\n"},{"id":"305177","messageId":"CACsJy8AMDW2w=xnAYDLTEN5MVxj+5JuiFnXGD1JFbD=RgLDcfA@mail.gmail.com","threadId":"44381","inReplyTo":"20161027210458.ptzh4y75dkfaixeo@sigill.intra.peff.net","subject":"Re: Expanding Includes in .gitignore","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2016-10-30T03:09:25Z","receivedAt":"2016-10-30T03:10:01Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Fri, Oct 28, 2016 at 4:04 AM, Jeff King <peff@peff.net> wrote:\n> On Thu, Oct 27, 2016 at 12:48:34PM -0700, Jacob Keller wrote:\n>\n>> > I think the normal behavior in such \"foo.d\" directory is to just sort\n>> > the contents lexically and read them in order, as if they were all\n>> > concatenated together, and with no recursion. I.e., behave \"as if\" the\n>> > user had run \"cat $dir/*\".\n>>\n>> Yea, this is the normal behavior, and the user is expected to order\n>> their files lexically such as \"00-name\", \"50-name\" and so on. Pretty\n>> traditional for a lot of newer configurations.\n>\n> One thing I will say about this approach is that you can implement it\n> without any changes in git by doing:\n>\n>   path=.git/info/exclude\n>   cat $path.d/* >$path\n>\n> and I have seen several config mechanisms basically do that (e.g.,\n> Debian packaging for a program that doesn't have its own \".d\" mechanism,\n> but needs to grab config provided by several separate packages).\n\nMy first thought at this .git/info/exclude.d was \"oh no I have to\nteach untracked cache about new dependencies, or at least disable it\nuntil it can deal with exclude.d\", but this \"cat\" approach simplifies\nthings and should keep untracked cache unchanged.\n\nThere may be complication with negative patterns though. The user may\nwant to limit the effect of negative patterns within individual\nexclude files in exclude.d so a negative pattern in exclude.d/a won't\ninfluence anything in exclude.d/b (easier to reason, safer to compose\ndifferent exclude sets). The plain \"cat\" would lose file boundary info\nthat we need. I'm not sure. But I'll dig more into it when patches\nshow up.\n-- \nDuy\n"},{"id":"305178","messageId":"CACsJy8CJMbLeyWV-V-DaQC2L9yfJnKp5e=F=HoL+9P-7bJ_yfA@mail.gmail.com","threadId":"44381","inReplyTo":"cc23eece-d693-9e40-78fe-3bafe6bcad3a@pelly.co","subject":"Re: Expanding Includes in .gitignore","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2016-10-30T03:16:13Z","receivedAt":"2016-10-30T03:16:51Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Fri, Oct 28, 2016 at 4:32 PM, Aaron Pelly <aaron@pelly.co> wrote:\n> Or how about a new githook that can intelligently create or return the\n> details? This would be my least favourite option unless it was\n> configured in an obvious place.\n\nI wonder if smudge/clean filters can be used to recreate in-tree\n.gitignore from .gitignore.d/*.\n-- \nDuy\n"},{"id":"305182","messageId":"20161030125402.y2swumdomymigjxi@sigill.intra.peff.net","threadId":"44381","inReplyTo":"cc23eece-d693-9e40-78fe-3bafe6bcad3a@pelly.co","subject":"Re: Expanding Includes in .gitignore","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-10-30T12:54:02Z","receivedAt":"2016-10-30T12:54:11Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Oct 28, 2016 at 10:32:07PM +1300, Aaron Pelly wrote:\n\n> On 28/10/16 15:54, Junio C Hamano wrote:\n> > Jeff King <peff@peff.net> writes:\n> > \n> >> However, as I said elsewhere, I'm not convinced this feature is all that\n> >> helpful for in-repository .gitignore files, and I think it does\n> >> introduce compatibility complications. People with older git will not\n> >> respect your .gitignore.d files. Whereas $GIT_DIR/info is purely a local\n> >> matter.\n> > \n> > As I do not see the point of making in-tree .gitignore to a forest\n> > of .gitignore.d/ at all, compatibility complications is not worth\n> > even thinking about, I would have to say.\n> \n> Well; that saves some work. :)\n> \n> I do not suggesting making this mandatory. I think it adds value and it\n> is a common and understood mechanism. But, if it is abhorrent, consider:\n> \n> There is precedent for including files in git-config. This could be\n> extended to ignore files. The code is not similar, but the concept is. I\n> could live with it.\n\nYes, but note that we don't have in-tree config files, either (to large\ndegree because of the security implications).\n\nPerhaps Junio can clarify himself, but I took his statement to mean only\nthat in-tree .gitignore.d is not worth worrying about, but that\n$GIT_DIR/info/exclude.d or similar would be OK (but perhaps I\ninterpreted that way because that's my own position :) ).\n\n> Or how about a new githook that can intelligently create or return the\n> details? This would be my least favourite option unless it was\n> configured in an obvious place.\n\nThat seems more complicated than is really merited, and probably doesn't\nperform great either (it's an extra forked process for almost every git\noperation). And obviously would not work for an in-tree solution anyway,\nas we do not want to run arbitrary code.\n\n-Peff\n"}]}