Re: [2.22.0] difftool no longer passes through to git diff if diff.tool is unset

["Pugh, Logan" <Logan.Pugh@austintexas.gov>]

> Well, it _is_ true that you can use it the same way. It's just that you
> need to configure it to use whatever 3rd-party tool you want (and if you
> do not want to configure a tool, then you are better off just using
> git-diff directly). It was only due to a bug/historical accident that it
> behaved just like git-diff in the no-index case (but not in the regular
> case -- AFAICT, that would have been broken for your script always).

Yes, it would seem that I had only stumbled upon the broken behavior 
because of my --no-index use case, but at least the inconsistency is fixed.

> That does make some sense to me for your use case. But I'm worried it
> would be a worse experience for people new to difftool (they run it and
> scratch their heads why it does not do anything different, whereas now
> they get walked through an interactive configuration).

That is a fair point. UX matters even for CLI programs. Prior to it 
being fixed, I myself was confused as to why I was getting a git-diff 
output when trying to use an external tool with git-difftool but hadn't 
configured it correctly. At least now there is some feedback when the 
configuration is invalid.

> In the meantime, I think you can probably switch behavior in your script
> by checking if the diff.tool config is set. It might be nice if difftool
> had a better way to query that without you having to know if it's
> configured.

What I ended up doing in my app was just requiring the user to be 
explicit (via separate arguments) about whether they wanted to use 
git-diff or git-difftool. My app also accepts additional arguments that 
get passed through to git-diff/difftool and I didn't want to have to 
check those in addition to git-config. I think that would have been 
significantly more complex to implement.

> Or in your case I suppose even better would just be an
> option like "--if-not-configured-just-use-regular-diff". Then it would
> do what you want, without impacting users who do want the interactive
> setup.

If such an option was considered I would be in favor of it. Maybe call 
it "--no-tutorial" or perhaps "--diff-fallback".

But having fixed my app, I'm content with the status quo too, now.

Thanks,

Logan