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

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 4, 2007, 13:14 UTC
Message-ID: <7vy7ej9g38.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <20071004125641.GE15339@genesis.frugalware.org>

Miklos Vajna <vmiklos@frugalware.org> writes:

Show 8 quoted lines

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