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

From: Junio C Hamano <gitster@pobox.com>
Date: May 23, 2011, 19:22 UTC
Message-ID: <7vpqn9usqt.fsf@alter.siamese.dyndns.org>
In-Reply-To: <BANLkTi=Uf8X+Bkd+CZ9qz0wXhHn8wwYzrA@mail.gmail.com>

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

Show 10 quoted lines

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