Re: A few usability question about git diff --cached
- From
- David Tweed <david.tweed@gmail.com>
- Date
- Oct 5, 2007, 05:22 UTC
- Message-ID
- <e1dab3980710042222u3e1fc21dtf4b90056fb36eaf0@mail.gmail.com>
- In-Reply-To
- <vpqtzp7ndn3.fsf@bauges.imag.fr>
On 10/4/07, Matthieu Moy <Matthieu.Moy@imag.fr> wrote:
Show 10 quoted lines
> 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