Re: js/difftool-no-index, was Re: What's cooking in git.git (May 2019, #02; Tue, 14)

From: Junio C Hamano <gitster@pobox.com>
Date: May 19, 2019, 01:44 UTC
Message-ID: <xmqqsgtb1am1.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <nycvar.QRO.7.76.6.1905172025450.46@tvgsbejvaqbjf.bet>

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

Show 13 quoted lines

> Hi Junio,
>
> On Wed, 15 May 2019, Junio C Hamano wrote:
>
>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>>
>> I was imagining what would happen if we treat _everything_ in the two
>> directories being compared by "difftool --dir-diff --no-index" as if it
>> is tracked.
>
> Isn't this exactly what `git difftool --no-index` *without* `--dir-diff`
> does already (although without copying or hardlinking or symlinking any
> files)?

If that is the case, then I would imagine that running that command for the user, instead of refusing to work, would give a more pleasant end-user experience. No?

Unless we anticipate that we might dwim incorrectly and mistake a request to compare two things, to which the distinction between tracked and untracked matters, as a request to compare two directories that are not under Git control, that is. If such an incorrect dwim were a possibility, then it is helpful to refuse with "when comparing two non-git-controlled directories, you cannot use the '--dir-diff' mode", as that would not silently give an incorrect output to the users.

In any case, all of the above can be left for future improvements. Getting close to the final, I think it is preferrable to have a "refuse to stop early" (i.e. the patch that is already in 'next') instead of "do what the user meant" whose implementation may become more involved (and error prone).

Thanks.