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

["David Tweed" <david.tweed@gmail.com>]

On 10/4/07, Matthieu Moy <Matthieu.Moy@imag.fr> wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> It makes more sense to me.
>
> For me, a "cache" is a fast-access copy of something, that I can
> rebuild at any time. Cache should be only a matter of performance, if
> the "cache" for an application changes its functionality, it means the
> cache has been too optimistic. Git's index is not that, "git add"
> means "add this to the index", which itself means "put that in the
> list of things to commit", and not "get a copy of that to work faster
> with it".

Just to say this interpretation is also the natural interpretation I
have for the term "cached", and it confused me no end when I was first
learning about git that the index was referred to as a cache. To be
fair, git the documentation was in flux at that time and it's now
referred too as a cache in very few places now.

An example of the kind of thing I have to think carefully about even
now, Junio said in a different mail:

"--cached means work only on the "cached information in index."

If I understand correctly, the term "cached information in index" is
more correctly "stored information in index" (or perhaps more
technically "staged information in index") since there may be
information in there which isn't a cache because it's no longer
present anywhere else (ie, not in a commit yet but also changed in the
working tree).

It's not a big thing, but the usage of cached in git still quite confuses me.

-- 
cheers, dave tweed__________________________
david.tweed@gmail.com
Rm 124, School of Systems Engineering, University of Reading.
"we had no idea that when we added templates we were adding a Turing-
complete compile-time language." -- C++ standardisation committee