mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Johannes Schindelin <>
To: Junio C Hamano <>
Subject: Re: js/difftool-no-index, was Re: What's cooking in git.git (May 2019, #02; Tue, 14)
Date: Wed, 22 May 2019 00:28:00 +0200 (CEST)	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Hi Junio,

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

> Johannes Schindelin <> writes:
> > On Wed, 15 May 2019, Junio C Hamano wrote:
> >
> >> Johannes Schindelin <> 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`.


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

      reply	other threads:[~2019-05-21 22:28 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-13 16:11 What's cooking in git.git (May 2019, #02; Tue, 14) Junio C Hamano
2019-05-13 22:20 ` Elijah Newren
2019-05-14  9:54 ` js/difftool-no-index, was " Johannes Schindelin
2019-05-15  1:28   ` Junio C Hamano
2019-05-15  8:24     ` Johannes Schindelin
2019-05-15  8:50       ` Junio C Hamano
2019-05-17 18:27         ` Johannes Schindelin
2019-05-19  1:44           ` Junio C Hamano
2019-05-21 22:28             ` Johannes Schindelin [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).