Re: [PATCH] Improve errors from 'git diff --no-index'.

[Junio C Hamano <gitster@pobox.com>]

Anthony Foiani <anthony.foiani@gmail.com> writes:

> $ ls -al /tmp/{foo,bar}
> -rw-rw-r--. 1 tony tony 0 May 22 10:09 /tmp/bar
> -rw-rw-r--. 1 tony tony 0 May 22 10:00 /tmp/foo
>
> $ # current git tip:
> $ git diff /tmp/{foo,bar}
>
> $ # with my patch:
> $ ../git/git-diff /tmp/{foo,bar}
> warning: neither '/tmp/foo' nor '/tmp/bar' are tracked, forcing --no-index

I actually consider this a regression. We are giving an output that the
user wanted to see, and I do not see a reason why we need to warn.

A tangent.

One thing that I have always been unhappy about --no-index is that it does
not really mesh well with the notion of what a "git diff" is. "git diff"
inherently is an operation to take two collections of contents labeled
with paths, and show series of patch output between corresponding paths in
these collections, while rename/copy detection may affect the definition
of "correspoinding paths".

A typical "I know 'git diff' has a lot more features like color-words that
my platform 'diff' does not support, so let me use 'git diff' instead"
session does something like:

	$ git diff [--no-index] /tmp/foo /tmp/bar

but such a request does not compare "two collections of paths that have
corresponding paths" at all. We could say we are comparing a collection
that has tmp/foo with another that has tmp/bar, but then we should either
emit a delete patch for tmp/foo and a create patch for tmp/bar, or emit a
rename patch to create tmp/bar out of tmp/foo if we want to be consistent.

But that consistency goes totally against what the users would expect.
This inconsistency is not a fault of either the definition of "git diff"
nor the user's expectation. They are fundamentally different and the root
cause of it is that we support --no-index diff between randomly chosen two
files. I am not saying we should drop that feature, but it does not change
the fact that we had to add extra code in the output codepath only to
support this "outside git" use case to suppress rename information (and
probably other things I do not remember).

The _only_ use of --no-index that is in line with what "git diff" does is
to compare two directories as the "two collections of contents" above,
i.e.

	$ git diff --no-index old/ new/

and then support pathspecs, like this:

	$ git diff --no-index old/ new/ -- Makefile '*.c'

But I do not think the current implementation does not even support this
only sane usecase.