Re: "git -c web.browser=w3m help -w help" still kicks firefox

[Jeff King <peff@peff.net>]

On Mon, Aug 23, 2010 at 11:05:04AM -0700, Junio C Hamano wrote:

> A "trivial fix" would be to pass this info through the execv_git_cmd()
> interface by either exporting it via an environment variable or by
> modifying the command line options, but I am not sure about the possible
> fallouts from such a change.  For example, does "git -c var=value config ..."
> work sensibly when what "config" is told to do (say, remove a section)
> contradicts with having the named var with a given value?
> 
> I am wondering if this is worth fixing it in the first place.

IMHO, it needs to be fixed. This bug means "git -c foo=bar X" silently
ignores the new value of "foo" if "X" is an external or a shell script.
For something like "help" it is a minor inconvenience, but I can
certainly see this causing data loss. Just in 30 seconds of grepping, I
see that "git -c mergetool.keepbackup=true mergetool" would be silently
ignored. Oops.

The environment is the only sensible way to pass this down, because we
need to hit not just externals, but things like "git config" invocations
from shell scripts. IOW, "git -c" really is about executing in a
sub-environment that pretends that config is set. Obviously we would
need to quote and unquote when using the environment as a transport (or
do something horrible like making a temporary config file and pointing
at it through the environment).

As for "git config", I would assume that "-c" parameters impact how
config itself behaves, but have no bearing at all on actual
configuration that it writes. I don't know if that is the case now,
though.

-Peff