Jeff King <[email protected]> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
