Re: A few usability question about git diff --cached

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

Miklos Vajna <vmiklos@frugalware.org> writes:

> On Thu, Oct 04, 2007 at 02:27:41PM +0200, Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com> wrote:
>> Why do we have the option "--cached" and not "--index"?
>
> according to glossary.txt, 'cache' is an obsolete for 'index'. probably
> this is the reason
>
> probably cache.h will be never renamed to index.h, i don't know if diff
> --cached will be ever renamed to diff --index

Probably never.

Some commands support both --index and --cached and have
different meanings.  For them,

 * --index means work on both index and work tree;
 * --cached means work only on index and ignore work tree.

In the case of "diff --cached", the latter is exactly what's
happening.  We do not say "git diff-index --index $commit"
because "git diff-index" (and by extension, when you give only
one commit to "git diff" as parameter) is all about a commit vs
your uncommitted changes, so having you say "--index" is just
silly.  "git diff --cached" is just a shorthand for "git diff
--cached HEAD".  Because --cached would make sense to no other
form of diff, its presense by definition means you are talking
about the one-tree form of diff i.e. compare a commit with your
uncommitted changes.

An example of a command that supports both is "git apply".
Actually it is an extreme case in that it allows "no index" form
of operation, so it has "git apply", "git apply --cached", and
"git apply --index".  The --cached would only apply to index
without touching work tree, the --index would apply to both
index and work tree.