From: Jeff King <peff@peff.net>
Date: Fri, 22 Mar 2013 18:33:06 GMT
Subject: Re: feature request - have git honor nested .gitconfig files
Message-ID: <20130322183306.GA32448@sigill.intra.peff.net>
In-Reply-To: <20130322182211.GD12223@google.com>

On Fri, Mar 22, 2013 at 11:22:11AM -0700, Jonathan Nieder wrote:

>  * Maintaining configuration per repository to record a rather simple
>    is more complicated than ideal.  It would be easier to understand
>    the configuration if ~/.gitconfig could spell out the rule
>    explicitly:
> 
> 	[include]
> 		path = cond(starts_with($GIT_DIR, ~/dev/),
> 			    ~/.config/git/dev-config,
> 			    ~/.config/git/nondev-config)
> 
>    This means supporting an extension language in the config file.
>    It sounds hard to do right, especially considering use cases like
>    "User runs into trouble, asks a privileged sysadmin to try running
>    a command in her untrusted repository", but it is worth thinking
>    about how to do.

I'd rather not invent a new language. It will either not be featureful
enough, or will end up bloated. Or both. How about something like:

  [include]
       exec = "
         case \"$GIT_DIR\" in)
           */dev/*) cat ~/.config/git/dev-config ;;
                 *) cat ~/.config/git/nondev-config ;;
          esac
       "

It involves a shell invocation, but it's not like we parse config in a
tight loop. Bonus points if git provides the name of the current config
file, so exec can use relative paths like:

  cat "$(dirname $GIT_CONFIG_FILE)"/dev-config

>  * The "Includes" facility is annoyingly close to being helpful.
>    An include.path setting from ~/.gitconfig cannot refer to $GIT_DIR
>    by name.

Yeah, we do not allow variable expansion at all beyond the usual path
mechanisms. I think if you had $GIT_DIR, though, it would end up
annoying.  You do not want one file in ~/.config/git per $GIT_DIR, so
you would need some way of munging $GIT_DIR into your naming scheme.

-Peff