On Mon, Aug 23, 2010 at 09:02:36PM +0200, Alex Riesen wrote: > Maybe it is worth fixing, but on a case-by-case basis? > > I mean changing the execv_git_cmd interface (or create a new execv > function), so that it can get the list of config vars to pass down to > the callee. A trivial case of its use would be to just pass the > current config (or, more likely, none). Or, one could give it its own > list of config parameters. I don't think that is enough. We don't necessarily know which config options will be relevant to exec'd processes. We could be running some user-defined command that calls a bunch of other git commands. Or a hook, for that matter. Which does bring up one interesting boundary. If I run: git -c receive.denyDeletes=false git push what should happen? Obviously with cross-server communication the environment won't get passed. I am inclined to say that even for local cases, receive-pack should clear the string. Certainly for the sake of consistency between local and remote transports, but it may also be a security issue (in most cases, no, since you would have to be exec'ing receive-pack directly, and you are clearly already running an arbitrary command, but I can see somebody perhaps crossing a setuid boundary with receive-pack). -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