On Thu, Feb 2, 2012 at 22:11, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Kyle Moffett <kyle@xxxxxxxxxxxxxxx> writes:
>
>> Alternatively, you could extend the recent proposal for GIT config
>> "include" statements so that something like this works:
>>
>> [include]
>> exec = echo "deploy.prefix = `cat /etc/SERVER_ROLE`"
>> exec = /usr/local/bin/git-config-for-ldap-user
>
> Erh...
>
> Running known stuff from your own .git/config may be justifiable as "at
> your own risk", but if we consider sources that are not under your direct
> control, such as /etc/gitconfig and whatever your project encourages you
> to include from your .git/config,... eek.
Well yes, but running commands from .git/config is exactly what the OP
requested, and if it applies to .git/config it should also be
applicable to other trusted include sources too, no?
Perhaps allow config files to perform a "trusted" include, EG:
[include]
trusted_exec = /usr/local/bin/site-specific-config-program
blob = v1.0:src/gitconfig
By default, the only files which would be trusted are /etc/gitconfig,
~/.gitconfig, and .git/config (but ONLY if it has the same owner and
mode go-w), and they would only pass trust on to other files if they
use "trusted_*" include lines.
Also, since "include" is intended to introduce a
non-backwards-compatible change in behavior, perhaps a totally
different format should be used, EG:
$include exec_trusted /usr/local/bin/site-specific-config-program
$include blob v1.0:src/gitconfig
Something that would cause noticeable warnings in older versions of
git instead of silently ignoring the desired config includes.
Just a few thoughts.
Cheers,
Kyle Moffett
--
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