Hi Junio, On Tue, 29 Nov 2016, Junio C Hamano wrote:
> Johannes Schindelin <johannes.schinde...@gmx.de> writes: > > > So the suggestion by both you and Peff, to use an environment variable, > > which is either global, or requires the user to set it manually per > > session, is simply not a good idea at all. > > As I already said, I do not have a strong preference between config > and env. I raised the env as a possible alternative that you can > think about its pros and cons, and as I already said, if you thought > and your concluded that config would work better for your needs, > that is fine by me. The env flat out fails, on the grounds of not integrating nicely into a Git for Windows installer. 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. And I still see what is bad about the config "solution": it *creates* a chicken-and-egg problem with the order of config reading vs running scripts. It *creates* problems for requiring to spawn a `git config` call because reading the config in-process would mess up the global variables and environment *beyond repair*, making it *impossible* to even spawn the git-legacy-difftool Perl script. In short: the config setting now works. But it is ugly as hell. I wish I never had listened to you. Ciao, Dscho
