Re: feature request - have git honor nested .gitconfig files

From: Jonathan Nieder <jrnieder@gmail.com>
To: Josh Sharpe <josh.m.sharpe@gmail.com>
Cc: git@vger.kernel.org, Jeff King <peff@peff.net>
Subject: Re: feature request - have git honor nested .gitconfig files
Date: Fri, 22 Mar 2013 11:22:11 -0700	[thread overview]
Message-ID: <20130322182211.GD12223@google.com> (raw)
In-Reply-To: <CAM2RUGOOWnxRd2=04-NmKTC+tvnCD=ebgmmiexHas5bwyYrm4w@mail.gmail.com>

Hi Josh,

Josh Sharpe wrote:

> For example, I have my ~/.gitconfig that has one email address in it,
> but I also have multiple repos inside ~/dev which I want to use a
> different email address for.  The only way to do that now is to edit
> all of these: ~/dev/*/.git/conf -- and there are lots of them, and new
> repos get added all the time - and I forget.

A couple of ideas using existing git features:

 - A wrapper script around "git init" can take care of setting up the
   shared configuration appropriately based on the repository path.

 - The extra configuration can be applied on a per-cwd instead of a
   per-repository basis.  Some shells provide a PROMPT_COMMAND
   facility that can be used to run a command (for example set up
   environment) each time the prompt is displayed.  A PROMPT_COMMAND
   could set the environment variable EMAIL or GIT_EMAIL based on the
   value of $PWD.

Room for improvement:

 * A new repository can be created by "git init" or "git clone" and
   the path where the repository will live is not immediately obvious
   from the command line, so setting up thorough wrappers is not
   actually that easy.

   So this sounds like a good place to provide a hook.  (It could be
   called new-repository or something.)

 * 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.

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

Hope that helps,
Jonathan