Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > The downside is that we actually *do* go through Perl to do that. Only to > go back to a builtin. Which is exactly the thing I intended to avoid. > > If we do not go through Perl, we have to set up the git directory and > parse the config in git.c *just* to figure out whether we want to > magically forward difftool to builtin-difftool. That is not only ugly, but > has potential side effects I was not willing to risk. I won't accept the latter anyway, so do not worry ;-) > In any case, this feature flag will be there only for one or two Git for > Windows releases, to give early adopters a chance to send me bug reports > about any regressions. I think that is sensible. I suspect that for early detection of breakages, you do not need to invent and force people to use a completely new "mechanism" to switch between two implementations. Can't you route the control upon seeing "git difftool" to your experimental "C" difftool and check the configuration there? Then you can decide to run_command() a non-builtin one depending what the configuration says---that way, you would incur cost of spawning Perl only when you need it, no?