On Wed, Jun 17, 2015 at 4:20 AM, Jeff King <peff@xxxxxxxx> wrote: > On Tue, Jun 16, 2015 at 03:49:07PM -0400, Jeff King wrote: > >> Another option would be to stop trying to intercept stdin in git.c, and >> instead make this a feature of run-command.c. That is, right before we >> exec a process, tee its stdin there. That means that you cannot do: >> >> GIT_TRACE_STDIN=/tmp/foo.out git foo >> >> to collect the stdin of foo. But that is not really an interesting case >> anyway. You can run "tee" yourself if you want. The interesting cases >> are the ones where git is spawning a sub-process, and you want to >> intercept the data moving between the git processes. > > Hmm. I guess we do not actually have to move the stdin interception > there. We can just move the config-checking there, like the patch below. > > It basically just converts trace.foo.bar into GIT_TRACE_BAR when we are > running "foo" as a git command. This does work, but is perhaps > potentially confusing to the user, because it only kicks in when _git_ > runs "foo". IOW, this works: > > git config trace.upload-pack.foo /path/to/foo.out > git daemon I wonder if we could do it a bit differently. Instead of GIT_TRACE_STDIN, I would add GIT_TRACE_HOOK that points to a script. Whenever a command is run via run-command interface, the actual command line to be executed would be "<hook script> <command> <arguments>". Because this script is given full command line, it can decide to trace something if the command name is matched (or arguments are matched) or just execute the original command. It's more flexible that trace.* config keys. We also have an opportunity to replace builtin commands, like pack-objects, in command pipeline in fetch or push with something else, to inject errors or whatever. It can be done manually, but it's not easy or convenient. -- Duy -- 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