Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > The config kinda works now. But for what price. It stole 4 hours I did not > have. When the libexec/git-core/use-builtin-difftool solution took me a > grand total of half an hour to devise, implement and test. > > And you know what? I still do not really see what is so bad about it. I was wondering if I should explain myself again, even though I do not see what good it would do, as clearly my point did not come across in the other emails. And then you would just complain that I am making work for you. Clearly you do not seem to see why placing random files in $GIT_EXEC_PATH, which is a place for git subcommand implementations, is wrong, so I won't repeat it to you again. But you need to remember that you are not working on a Windows-only project. In non-Windows environment, many users would not have write access to /usr/libexec/git-core directory, but it is not just easy for them to write into ~/.gitconfig, but that is the way they are accustomed to, in order to affect the behaviour of Git for them. As to "I have to spawn config", I think it is sensible to start the cmd_difftool() wrapper without adding RUN_SETUP to the command table, then call git_config_get_bool() to check the configuration only from system and per-user files, and then finally either call into builtin_difftool() where setup_git_directory() is called, or spawn the scripted difftool, as Peff already said. Your "users opt-in while installing" is not about setting per-repository option. Calling git_config*(), setup_git_directory() and then git_config*() in this order should be safe, as setup_git_directory() would clear potentially cached configuration values read by any previous git_config*() calls, so any configuration enquiry made by builtin_difftool() would read from all three sources, not just system and per-user. So there is no chicken-and-egg issue, either.