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 -- 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