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