{"thread":{"id":"36975","subject":"Re: How should git-config include.path option work in ~/.gitconfig file?","startedAt":"2014-06-21T10:08:03Z","lastAt":"2014-06-23T17:36:15Z","messageCount":3,"participants":["Jeff King","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"244827","messageId":"20140621100803.GB16599@sigill.intra.peff.net","threadId":"36975","inReplyTo":"CAK6hiNhumFhKd9tjr07SgtZe23LwW8RKSp3BbwVRh06-L0C8EA@mail.gmail.com","subject":"Re: How should git-config include.path option work in ~/.gitconfig file?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-06-21T10:08:03Z","receivedAt":"2014-06-21T10:08:03Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"[+cc mailing list]\n\nOn Sat, Jun 21, 2014 at 03:16:05AM -0600, Cox, Michael wrote:\n\n> I discovered the new (to me, at least) git config include.path option\n> recently and tried using it to include a file, .gitremotes in my git\n> worktree.  The .gitremotes file contains a remote.upstream section\n> containing information (url, fetch, etc.) for the upstream remote I'm using\n> to fetch updates for the project I'm working on, e.g.\n> \n> [remote \"upstream\"]\n> url = http://github.com/diydrones/ardupilot\n> fetch = +refs/heads/*:refs/remotes/upstream/*\n> \n> When I add\n> \n> [include]\n> path = ../.gitremotes\n> \n> to my .git/config file, everything works as expected.\n\nSo far so good, though note the potential security implications. If the\nupstream you fetch from puts something malicious into .gitremotes, they\ncould execute arbitrary code (e.g., by setting up external diff config).\n\nThat may be a tradeoff you're OK with, but I wanted to point it out to\nmake sure you are aware.\n\n> I then thought I'd like to make this work for all my repositories by\n> default by adding the above include.path option to my global ~/.gitconfig\n> file. This way I would not have to run \"git config include.path\n> ../.gitremotes\" for each of my repositories and the .gitremotes file would\n> server as documentation of the official remote repositories for the\n> project. The documentation for the git config include.path option does\n> state that relative paths are relative to the including config file. But\n> the ~/.gitconfig file is supposed to contain common configuration options\n> that appear in all your git repositories.\n\nThe including config file in that case would be ~/.gitconfig, and the\nincluded path is relative to it.\n\nYour final sentence seems to me to be the one that introduces the\nconfusion. Options in .gitconfig do not \"appear in all your git\nrepositories\". Rather, when a git command is run, it consults the\nrepo-local $GIT_DIR/config, the global ~/.gitconfig file, and the\nsystem-level /etc/gitconfig.\n\n> So is this a bug or a feature?\n\nFeature. :)\n\n> It seems like the currently documented behavior of include.path and\n> .gitconfig are conflicting. I can see how having include.path\n> statements in your .gitconfig file that are processed immediately\n> would be useful for modularizing your .gitconfig file, but I think my\n> use case is also a valuable use of the include.path functionality.\n> Not sure how to syntactically express the deferral of the include file\n> processing in the .gitconfig file, though.\n\nYes, the design of includes from ~/.gitconfig is very intentional, and\nnot going to change (and even if it weren't, we would have to deal with\nbackwards compatibility while changing it).  I agree what you are trying\nto do is a sane thing (the security implications of pointing straight\ninto the work-tree aside, you could easily be doing the same thing with\nanother file in $GIT_DIR, or any number of similar schemes).\n\nThere isn't currently a way to do what you want. I think we would need a\nnew syntax for it. Recently we discussed supporting environment\nvariables in expansions of path-oriented config variables. So something\nlike:\n\n  [include]\n  path = $GIT_DIR/../.gitremotes\n\nwould do what you want. We'd have to give some thought on what that\nshould do when $GIT_DIR is not set (e.g., when you run a git command\noutside of a repository). I'd be inclined to say that such an include\nshould be ignored (the naive shell interpretation would be to look for\n\"/../.gitremotes\", which is almost certainly not what the user wants).\n\n> P.S.  I searched the archive and found your patch submittal.  I wasn't sure\n> if I should post this to git@vger.kernel.org, so I decided it would be\n> better to check with the original feature developer first.  Sorry if that\n> was a violation of this mailing list's etiquette.\n\nThis is definitely the sort of thing that should be discussed on the\nmailing list. I've added it to the cc so we can continue the discussion\nthere.\n\n-Peff\n"},{"id":"244882","messageId":"20140623172913.GE4838@sigill.intra.peff.net","threadId":"36975","inReplyTo":"CAK6hiNjxeQ6sy1Uk_ApTgKT41cPE-NB1D+ec2JqFvog_9HeFZw@mail.gmail.com","subject":"Re: How should git-config include.path option work in ~/.gitconfig file?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-06-23T17:29:13Z","receivedAt":"2014-06-23T17:29:13Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Jun 22, 2014 at 01:00:53PM -0600, Cox, Michael wrote:\n\n> I like the idea of recognizing environment variable syntax in config files,\n> at least a feature that would allow *some* config variables to be specified\n> as accepting environment variable syntax.  It adds a lot of flexibility,\n> but I'm sure it might also introduce security issues that I am completely\n> unaware of (like the  issue you made me aware of above).\n\nI don't think there are any security issues; if you control the\nenvironment, you can already execute arbitrary code with git.\n\nNow we just need somebody to volunteer to implement it. :)\n\n-Peff\n"},{"id":"244885","messageId":"xmqqegyfcyuo.fsf@gitster.dls.corp.google.com","threadId":"36975","inReplyTo":"20140621100803.GB16599@sigill.intra.peff.net","subject":"Re: How should git-config include.path option work in ~/.gitconfig file?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-06-23T17:36:15Z","receivedAt":"2014-06-23T17:36:15Z","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> ... Recently we discussed supporting environment\n> variables in expansions of path-oriented config variables. So something\n> like:\n>\n>   [include]\n>   path = $GIT_DIR/../.gitremotes\n>\n> would do what you want. We'd have to give some thought on what that\n> should do when $GIT_DIR is not set (e.g., when you run a git command\n> outside of a repository). I'd be inclined to say that such an include\n> should be ignored (the naive shell interpretation would be to look for\n> \"/../.gitremotes\", which is almost certainly not what the user wants).\n\nI agree with everything in the above paragraph.\nThanks for forwarding.\n"}]}