Hi, On Mon, 4 Jun 2007, Martin Waitz wrote: > On Mon, Jun 04, 2007 at 04:57:35PM +0100, Johannes Schindelin wrote: > > I actually would like it more if the calling program did the > > interpolation itself. > > That's another possibility, perhaps along the line of git_config_int. Maybe... > > So, for example if you want a script to access whatever.my.url, and > > want to allow to interpolate any environment variable, why not > > > > url=$(eval $(git config whatever.my.url)) > > Well, complete shell syntax does too much: it also supports $() and > friends. Good point. > > I am just hesitant to change the existing behaviour, and possibly > > introduce weird breakages. (There could even be some unwanted env > > leakages in programs like gitweb...) > > exactly. > > So should we simply update semantics of config variables to not require > any environment variables? Well, actually there is a perfect example when you would want to do even more than just expanding environment variables: aliases. I'm happy to understand the config as a relatively versatile key/value store, without much in the way of pre- or post-processing from git-config or git_config(). But if there are a few callers of git_config() which want environment variable interpolation, git_config_expand_envs() would be good. Ciao, Dscho - 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
