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

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: May 21, 2019, 22:28 UTC
Message-ID: <nycvar.QRO.7.76.6.1905220025440.46@tvgsbejvaqbjf.bet>
In-Reply-To: <xmqqsgtb1am1.fsf@gitster-ct.c.googlers.com>

Hi Junio,

On Sun, 19 May 2019, Junio C Hamano wrote:

Show 17 quoted lines

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > 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?

The elephant in the room is that a user might think that --dir-diff makes copies (as promised) and lets their difftool clobber them files happily, only to find out that they clobbered the original files. And since they asked for `--no-index`, chances are that those files really are not tracked, so now they do not even have a way to revert that clobbering.

Seriously, I'd rather not DWIM `--no-index --dir-diff` to essentially do `--no-index --no-dir-diff`.

Ciao, Dscho

Show 18 quoted lines

> 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.
>
>