From: Junio C Hamano Date: Thu, 04 Oct 2007 13:14:51 GMT Subject: Re: A few usability question about git diff --cached Message-ID: <7vy7ej9g38.fsf@gitster.siamese.dyndns.org> In-Reply-To: <20071004125641.GE15339@genesis.frugalware.org> Miklos Vajna writes: > On Thu, Oct 04, 2007 at 02:27:41PM +0200, Paolo Ciarrocchi 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.