{"thread":{"id":"33258","subject":"feature request - have git honor nested .gitconfig files","startedAt":"2013-03-22T16:50:07Z","lastAt":"2013-03-24T07:14:45Z","messageCount":8,"participants":["Josh Sharpe","Jonathan Nieder","Jeff King","Thomas Rast","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"211957","messageId":"CAM2RUGOOWnxRd2=04-NmKTC+tvnCD=ebgmmiexHas5bwyYrm4w@mail.gmail.com","threadId":"33258","inReplyTo":null,"subject":"feature request - have git honor nested .gitconfig files","fromName":"Josh Sharpe","fromEmail":"josh.m.sharpe@gmail.com","sentAt":"2013-03-22T16:50:07Z","receivedAt":"2013-03-22T16:50:07Z","isPatch":false,"sender":{"key":"josh.m.sharpe@gmail.com","avatar":null},"body":"It'd be cool if I were able to override config settings at every\nnested directory.\n\nFor example, I have my ~/.gitconfig that has one email address in it,\nbut I also have multiple repos inside ~/dev which I want to use a\ndifferent email address for.  The only way to do that now is to edit\nall of these: ~/dev/*/.git/conf -- and there are lots of them, and new\nrepos get added all the time - and I forget.\n\nIf I could add ~/dev/.gitconfig and have the settings in that override\n~/.gitconfig then this would be way more manageable.  Obviously,\nindividual repo's .git/config should take ultimate precedence.\n\nThanks for the consideration!\n"},{"id":"211967","messageId":"20130322182211.GD12223@google.com","threadId":"33258","inReplyTo":"CAM2RUGOOWnxRd2=04-NmKTC+tvnCD=ebgmmiexHas5bwyYrm4w@mail.gmail.com","subject":"Re: feature request - have git honor nested .gitconfig files","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-03-22T18:22:11Z","receivedAt":"2013-03-22T18:22:11Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi Josh,\n\nJosh Sharpe wrote:\n\n> For example, I have my ~/.gitconfig that has one email address in it,\n> but I also have multiple repos inside ~/dev which I want to use a\n> different email address for.  The only way to do that now is to edit\n> all of these: ~/dev/*/.git/conf -- and there are lots of them, and new\n> repos get added all the time - and I forget.\n\nA couple of ideas using existing git features:\n\n - A wrapper script around \"git init\" can take care of setting up the\n   shared configuration appropriately based on the repository path.\n\n - The extra configuration can be applied on a per-cwd instead of a\n   per-repository basis.  Some shells provide a PROMPT_COMMAND\n   facility that can be used to run a command (for example set up\n   environment) each time the prompt is displayed.  A PROMPT_COMMAND\n   could set the environment variable EMAIL or GIT_EMAIL based on the\n   value of $PWD.\n\nRoom for improvement:\n\n * A new repository can be created by \"git init\" or \"git clone\" and\n   the path where the repository will live is not immediately obvious\n   from the command line, so setting up thorough wrappers is not\n   actually that easy.\n\n   So this sounds like a good place to provide a hook.  (It could be\n   called new-repository or something.)\n\n * Maintaining configuration per repository to record a rather simple\n   is more complicated than ideal.  It would be easier to understand\n   the configuration if ~/.gitconfig could spell out the rule\n   explicitly:\n\n\t[include]\n\t\tpath = cond(starts_with($GIT_DIR, ~/dev/),\n\t\t\t    ~/.config/git/dev-config,\n\t\t\t    ~/.config/git/nondev-config)\n\n   This means supporting an extension language in the config file.\n   It sounds hard to do right, especially considering use cases like\n   \"User runs into trouble, asks a privileged sysadmin to try running\n   a command in her untrusted repository\", but it is worth thinking\n   about how to do.\n\n * The \"Includes\" facility is annoyingly close to being helpful.\n   An include.path setting from ~/.gitconfig cannot refer to $GIT_DIR\n   by name.\n\nHope that helps,\nJonathan\n"},{"id":"211971","messageId":"20130322183306.GA32448@sigill.intra.peff.net","threadId":"33258","inReplyTo":"20130322182211.GD12223@google.com","subject":"Re: feature request - have git honor nested .gitconfig files","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-03-22T18:33:06Z","receivedAt":"2013-03-22T18:33:06Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Mar 22, 2013 at 11:22:11AM -0700, Jonathan Nieder wrote:\n\n>  * Maintaining configuration per repository to record a rather simple\n>    is more complicated than ideal.  It would be easier to understand\n>    the configuration if ~/.gitconfig could spell out the rule\n>    explicitly:\n> \n> \t[include]\n> \t\tpath = cond(starts_with($GIT_DIR, ~/dev/),\n> \t\t\t    ~/.config/git/dev-config,\n> \t\t\t    ~/.config/git/nondev-config)\n> \n>    This means supporting an extension language in the config file.\n>    It sounds hard to do right, especially considering use cases like\n>    \"User runs into trouble, asks a privileged sysadmin to try running\n>    a command in her untrusted repository\", but it is worth thinking\n>    about how to do.\n\nI'd rather not invent a new language. It will either not be featureful\nenough, or will end up bloated. Or both. How about something like:\n\n  [include]\n       exec = \"\n         case \\\"$GIT_DIR\\\" in)\n           */dev/*) cat ~/.config/git/dev-config ;;\n                 *) cat ~/.config/git/nondev-config ;;\n          esac\n       \"\n\nIt involves a shell invocation, but it's not like we parse config in a\ntight loop. Bonus points if git provides the name of the current config\nfile, so exec can use relative paths like:\n\n  cat \"$(dirname $GIT_CONFIG_FILE)\"/dev-config\n\n>  * The \"Includes\" facility is annoyingly close to being helpful.\n>    An include.path setting from ~/.gitconfig cannot refer to $GIT_DIR\n>    by name.\n\nYeah, we do not allow variable expansion at all beyond the usual path\nmechanisms. I think if you had $GIT_DIR, though, it would end up\nannoying.  You do not want one file in ~/.config/git per $GIT_DIR, so\nyou would need some way of munging $GIT_DIR into your naming scheme.\n\n-Peff\n"},{"id":"212007","messageId":"20130323000628.GM12223@google.com","threadId":"33258","inReplyTo":"20130322183306.GA32448@sigill.intra.peff.net","subject":"Re: feature request - have git honor nested .gitconfig files","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-03-23T00:06:28Z","receivedAt":"2013-03-23T00:06:28Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Jeff King wrote:\n> On Fri, Mar 22, 2013 at 11:22:11AM -0700, Jonathan Nieder wrote:\n\n>>                                     It would be easier to understand\n>>    the configuration if ~/.gitconfig could spell out the rule\n>>    explicitly:\n[...]\n>>    It sounds hard to do right, especially considering use cases like\n>>    \"User runs into trouble, asks a privileged sysadmin to try running\n>>    a command in her untrusted repository\", but it is worth thinking\n>>    about how to do.\n>\n> I'd rather not invent a new language. It will either not be featureful\n> enough, or will end up bloated. Or both. How about something like:\n>\n>   [include]\n>        exec = \"\n>          case \\\"$GIT_DIR\\\" in)\n>            */dev/*) cat ~/.config/git/dev-config ;;\n>                  *) cat ~/.config/git/nondev-config ;;\n>           esac\n>        \"\n\nYes, an existing language like shell or lua would presumably be the\nway to go.  The scary aspect of shell is the \"Prankster sets up a\nmalicious configuration, asks a sysadmin to help in her repository\"\nscenario.  Of course we already have that problem with command\naliases, but if the sysadmin has perfect spelling then aliases would\nnever trip, so...\n\nHopefully that's enough information for anyone interested to start and\nunderstand the relevant variables at play.\n\nThanks,\nJonathan\n"},{"id":"212026","messageId":"878v5ezlo1.fsf@pctrast.inf.ethz.ch","threadId":"33258","inReplyTo":"20130322183306.GA32448@sigill.intra.peff.net","subject":"Re: feature request - have git honor nested .gitconfig files","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2013-03-23T06:15:42Z","receivedAt":"2013-03-23T06:15:42Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> I'd rather not invent a new language. It will either not be featureful\n> enough, or will end up bloated. Or both. How about something like:\n>\n>   [include]\n>        exec = \"\n>          case \\\"$GIT_DIR\\\" in)\n>            */dev/*) cat ~/.config/git/dev-config ;;\n>                  *) cat ~/.config/git/nondev-config ;;\n>           esac\n>        \"\n>\n> It involves a shell invocation, but it's not like we parse config in a\n> tight loop. Bonus points if git provides the name of the current config\n> file, so exec can use relative paths like:\n\nWe do, however, parse config more than once:\n\n  $ strace git log -1 2>&1 | grep 'open.*config'\n  open(\"/home/thomas/.gitconfig\", O_RDONLY) = 3\n  open(\".git/config\", O_RDONLY)           = 3\n  open(\"/home/thomas/.gitconfig\", O_RDONLY) = 3\n  open(\".git/config\", O_RDONLY)           = 3\n  open(\"/home/thomas/.gitconfig\", O_RDONLY) = 3\n  open(\".git/config\", O_RDONLY)           = 3\n  open(\"/home/thomas/.gitconfig\", O_RDONLY) = 3\n  open(\".git/config\", O_RDONLY)           = 3\n\ngit-log might be somewhat of an extreme example, but I suspect it's at\nleast twice for all commands (once for repo detection and once for\nactual parsing).  So I further suspect that the slowdown in git's own\nshellscripts (rebase) would be quite large if you actually spawned two\nextra shells every time someone says 'git rev-parse ...'.\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"212033","messageId":"20130323080341.GA29768@sigill.intra.peff.net","threadId":"33258","inReplyTo":"20130323000628.GM12223@google.com","subject":"Re: feature request - have git honor nested .gitconfig files","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-03-23T08:03:41Z","receivedAt":"2013-03-23T08:03:41Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Mar 22, 2013 at 05:06:28PM -0700, Jonathan Nieder wrote:\n\n> > I'd rather not invent a new language. It will either not be featureful\n> > enough, or will end up bloated. Or both. How about something like:\n> >\n> >   [include]\n> >        exec = \"\n> >          case \\\"$GIT_DIR\\\" in)\n> >            */dev/*) cat ~/.config/git/dev-config ;;\n> >                  *) cat ~/.config/git/nondev-config ;;\n> >           esac\n> >        \"\n> \n> Yes, an existing language like shell or lua would presumably be the\n> way to go.  The scary aspect of shell is the \"Prankster sets up a\n> malicious configuration, asks a sysadmin to help in her repository\"\n> scenario.  Of course we already have that problem with command\n> aliases, but if the sysadmin has perfect spelling then aliases would\n> never trip, so...\n\nAnd also external diff, textconv, clean/smudge filters, and I'm probably\nforgetting more. Oh, and hooks. There's definitely a danger to running\narbitrary git commands against a maliciously constructed repo. We've\ntried to make upload-pack safe, so you can at least make your own safe\ncopy to examine. We could probably do more safety checks when the\nrunning user and repo owner or not the same, but it would be quite\ncomplicated, and in practice it does not seem to be that huge a problem.\n\n> Hopefully that's enough information for anyone interested to start and\n> understand the relevant variables at play.\n\nYeah, I'm not planning to work on this, but I'd be happy to review\npatches if somebody else wants to.\n\n-Peff\n"},{"id":"212034","messageId":"20130323080638.GB29768@sigill.intra.peff.net","threadId":"33258","inReplyTo":"878v5ezlo1.fsf@pctrast.inf.ethz.ch","subject":"Re: feature request - have git honor nested .gitconfig files","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-03-23T08:06:38Z","receivedAt":"2013-03-23T08:06:38Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Mar 23, 2013 at 07:15:42AM +0100, Thomas Rast wrote:\n\n> > It involves a shell invocation, but it's not like we parse config in a\n> > tight loop. Bonus points if git provides the name of the current config\n> > file, so exec can use relative paths like:\n> \n> We do, however, parse config more than once:\n> \n>   $ strace git log -1 2>&1 | grep 'open.*config'\n>   open(\"/home/thomas/.gitconfig\", O_RDONLY) = 3\n>   open(\".git/config\", O_RDONLY)           = 3\n>   open(\"/home/thomas/.gitconfig\", O_RDONLY) = 3\n>   open(\".git/config\", O_RDONLY)           = 3\n>   open(\"/home/thomas/.gitconfig\", O_RDONLY) = 3\n>   open(\".git/config\", O_RDONLY)           = 3\n>   open(\"/home/thomas/.gitconfig\", O_RDONLY) = 3\n>   open(\".git/config\", O_RDONLY)           = 3\n> \n> git-log might be somewhat of an extreme example, but I suspect it's at\n> least twice for all commands (once for repo detection and once for\n> actual parsing).  So I further suspect that the slowdown in git's own\n> shellscripts (rebase) would be quite large if you actually spawned two\n> extra shells every time someone says 'git rev-parse ...'.\n\nYeah, I knew we parsed multiple times in some cases, but I don't think\nit's that big a deal for a single command. But yeah, it might be\nnoticeable for a shell script which runs lots of git commands. Still, it\nwould only affect people who used the feature. And there is no reason\nthe config system could not learn to cache the results across a single\ninvocation, which would at least drop it to one shell per git command.\n\n-Peff\n"},{"id":"212079","messageId":"7vehf52rru.fsf@alter.siamese.dyndns.org","threadId":"33258","inReplyTo":"20130323080341.GA29768@sigill.intra.peff.net","subject":"Re: feature request - have git honor nested .gitconfig files","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-03-24T07:14:45Z","receivedAt":"2013-03-24T07:14:45Z","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> Yeah, I'm not planning to work on this, but I'd be happy to review\n> patches if somebody else wants to.\n\nI am not planning to work on this, and honestly speaking I would not\nbe very happy to see any patch in this area.\n"}]}