feature request - have git honor nested .gitconfig files

feature request - have git honor nested .gitconfig files

[Josh Sharpe]

It'd be cool if I were able to override config settings at every
nested directory.

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.

If I could add ~/dev/.gitconfig and have the settings in that override
~/.gitconfig then this would be way more manageable.  Obviously,
individual repo's .git/config should take ultimate precedence.

Thanks for the consideration!

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

[Jonathan Nieder]

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

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

[Jeff King]

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

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

[Jonathan Nieder]

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

>>                                     It would be easier to understand
>>    the configuration if ~/.gitconfig could spell out the rule
>>    explicitly:
[...]
>>    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
>        "

Yes, an existing language like shell or lua would presumably be the
way to go.  The scary aspect of shell is the "Prankster sets up a
malicious configuration, asks a sysadmin to help in her repository"
scenario.  Of course we already have that problem with command
aliases, but if the sysadmin has perfect spelling then aliases would
never trip, so...

Hopefully that's enough information for anyone interested to start and
understand the relevant variables at play.

Thanks,
Jonathan

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

[Thomas Rast]

Jeff King <peff@peff.net> writes:

> 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:

We do, however, parse config more than once:

  $ strace git log -1 2>&1 | grep 'open.*config'
  open("/home/thomas/.gitconfig", O_RDONLY) = 3
  open(".git/config", O_RDONLY)           = 3
  open("/home/thomas/.gitconfig", O_RDONLY) = 3
  open(".git/config", O_RDONLY)           = 3
  open("/home/thomas/.gitconfig", O_RDONLY) = 3
  open(".git/config", O_RDONLY)           = 3
  open("/home/thomas/.gitconfig", O_RDONLY) = 3
  open(".git/config", O_RDONLY)           = 3

git-log might be somewhat of an extreme example, but I suspect it's at
least twice for all commands (once for repo detection and once for
actual parsing).  So I further suspect that the slowdown in git's own
shellscripts (rebase) would be quite large if you actually spawned two
extra shells every time someone says 'git rev-parse ...'.

-- 
Thomas Rast
trast@{inf,student}.ethz.ch

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

[Jeff King]

On Fri, Mar 22, 2013 at 05:06:28PM -0700, Jonathan Nieder wrote:

> > 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
> >        "
> 
> Yes, an existing language like shell or lua would presumably be the
> way to go.  The scary aspect of shell is the "Prankster sets up a
> malicious configuration, asks a sysadmin to help in her repository"
> scenario.  Of course we already have that problem with command
> aliases, but if the sysadmin has perfect spelling then aliases would
> never trip, so...

And also external diff, textconv, clean/smudge filters, and I'm probably
forgetting more. Oh, and hooks. There's definitely a danger to running
arbitrary git commands against a maliciously constructed repo. We've
tried to make upload-pack safe, so you can at least make your own safe
copy to examine. We could probably do more safety checks when the
running user and repo owner or not the same, but it would be quite
complicated, and in practice it does not seem to be that huge a problem.

> Hopefully that's enough information for anyone interested to start and
> understand the relevant variables at play.

Yeah, I'm not planning to work on this, but I'd be happy to review
patches if somebody else wants to.

-Peff

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

[Jeff King]

On Sat, Mar 23, 2013 at 07:15:42AM +0100, Thomas Rast wrote:

> > 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:
> 
> We do, however, parse config more than once:
> 
>   $ strace git log -1 2>&1 | grep 'open.*config'
>   open("/home/thomas/.gitconfig", O_RDONLY) = 3
>   open(".git/config", O_RDONLY)           = 3
>   open("/home/thomas/.gitconfig", O_RDONLY) = 3
>   open(".git/config", O_RDONLY)           = 3
>   open("/home/thomas/.gitconfig", O_RDONLY) = 3
>   open(".git/config", O_RDONLY)           = 3
>   open("/home/thomas/.gitconfig", O_RDONLY) = 3
>   open(".git/config", O_RDONLY)           = 3
> 
> git-log might be somewhat of an extreme example, but I suspect it's at
> least twice for all commands (once for repo detection and once for
> actual parsing).  So I further suspect that the slowdown in git's own
> shellscripts (rebase) would be quite large if you actually spawned two
> extra shells every time someone says 'git rev-parse ...'.

Yeah, I knew we parsed multiple times in some cases, but I don't think
it's that big a deal for a single command. But yeah, it might be
noticeable for a shell script which runs lots of git commands. Still, it
would only affect people who used the feature. And there is no reason
the config system could not learn to cache the results across a single
invocation, which would at least drop it to one shell per git command.

-Peff

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

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> Yeah, I'm not planning to work on this, but I'd be happy to review
> patches if somebody else wants to.

I am not planning to work on this, and honestly speaking I would not
be very happy to see any patch in this area.