Johannes Schindelin [off-list ref] writes:
Hi,
On Thu, 4 Oct 2007, Junio C Hamano wrote:
quoted
* --cached means work only on index and ignore work tree.
I guess I could live with "--staged" as a synonym for "--cached" (and
maybe deprecating "--cached").
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".
So, to me (non-native speaker), "index" doesn't mean much, "cache" is
worse, it means something which isn't correct, and "staging area"
means the right thing (but is longer to type). For example, I
understand immediately when git-gui talks me about staging/unstaging
changes ;-).
--
Matthieu
On Thu, Oct 04, 2007 at 04:44:00PM +0200, Matthieu Moy wrote:
Johannes Schindelin [off-list ref] writes:
quoted
Hi,
On Thu, 4 Oct 2007, Junio C Hamano wrote:
quoted
* --cached means work only on index and ignore work tree.
I guess I could live with "--staged" as a synonym for "--cached" (and
maybe deprecating "--cached").
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".
Yes, the index differs from the work tree or HEAD temporarily, but most
of it's life it's just a fast-access copy of something that you can
rebuild at any time.
So it's partly a "cache", partly a "staging area", and "index" is as
good a term for it as any.
--b.
On 10/4/07, Matthieu Moy [off-list ref] wrote:
Johannes Schindelin [off-list ref] 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