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

From: Thomas Rast <trast@student.ethz.ch>
Date: Mar 23, 2013, 06:15 UTC
Message-ID: <878v5ezlo1.fsf@pctrast.inf.ethz.ch>
In-Reply-To: <20130322183306.GA32448@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 14 quoted lines

> 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