From: Denton Liu <liu.denton@gmail.com>
Date: Mon, 22 Apr 2019 18:33:56 GMT
Subject: Re: [PATCH 5/5] difftool: fallback on merge.guitool
Message-ID: <20190422183356.GA6730@dev-l>
In-Reply-To: <2a521a5c-4b5d-57aa-1e91-d4ec9b190fb7@jeffhostetler.com>

Hi Jeff,

On Mon, Apr 22, 2019 at 02:18:36PM -0400, Jeff Hostetler wrote:
> 
> 
> On 4/22/2019 1:07 AM, Denton Liu wrote:
> >In git-difftool.txt, it says
> >
> >	'git difftool' falls back to 'git mergetool' config variables when the
> >	difftool equivalents have not been defined.
> >
> >However, when `diff.guitool` is missing, it doesn't fallback to
> >anything. Make git-difftool fallback to `merge.guitool` when `diff.guitool` is
> >missing.
> >
> 
> Is this a well-defined operation?

I believe this is a yes.

> 
> I mean, we're assuming here that a 3-way gui merge tool (that probably
> expects 3 input pathnames and maybe a 4th merge-result pathname (and
> associated titles and etc)) can function sanely when only given the
> pair that a diff would have.
> 
> That is, we're assuming that the selected merge tool has a 2-way diff
> mode and that the command line args for the 2- and 3-way views are
> compatible.

If I read the code correctly, it seems like the only tool that is
strictly "merge-only" is tortoisemerge. In mergetools/tortoisemerge, we
have

	can_diff () {
		return 1
	}

which means it will refuse to run as a difftool.

In the case where it fails like this, it'll loudly complain to the user,
which'll give them a chance to fix their config. I believe that this is
desired behaviour and the patch adds on top of that.

Thanks,

Denton

> 
> Just a thought
> Jeff
> 
>