Re: Consistent terminology: cached/staged/index

[Drew Northup <drew.northup@maine.edu>]

On Sun, 2011-02-13 at 19:09 -0800, Pete Harlan wrote:
> On 02/13/2011 02:58 PM, Junio C Hamano wrote:
> >> --staged
> >> ~~~~~~~~
> >> diff takes --staged, but that is only to support some people's habits.
> > The term "stage" comes from "staging area", a term people used to explain
> > the concept of the index by saying "The index holds set of contents to be
> > made into the next commit; it is _like_ the staging area".
> > 
> > My feeling is that "to stage" is primarily used, outside "git" circle, as
> > a logistics term.  If you find it easier to visualize the concept of the
> > index with "staging area" ("an area where troops and equipment in transit
> > are assembled before a military operation", you may find it easier to say
> > "stage this path ('git add path')", instead of "adding to the set of
> > contents...".
> 
> FWIW, when teaching Git I have found that users immediately understand
> "staging area", while "index" and "cache" confuse them.
> 
> "Index" means to them a numerical index into a data structure.
> "Cache" is a local copy of something that exists remotely.  Neither
> word describes the concept correctly from a user's perspective.

According to the dictionary (actually, more than one) "cache" is a
hidden storage space. I'm pretty sure that's the sense most global and
therefore most appropriate to thinking about Git. (It certainly
describes correctly what web browser cache and on-CPU cache is doing.)
One would only think the definition you gave applied if they didn't know
that squirrels "cache" nuts. I don't think that the problem is the
idiom.

> I learned long ago to type "index" and "cached", but when talking (and
> thinking) about Git I find "the staging area" gets the point across
> very clearly and moves Git from interesting techie-tool to
> world-dominating SCM territory.  I'm surprised that that experience
> isn't universal.

Perhaps that helps you associate it with other SCM/VCS software, but it
didn't help me. When I realized that the "index" is called that BECAUSE
IT IS AN INDEX (of content/data states for a pending commit operation)
the sky cleared and the sun came out.

In all reality the closest thing Git has to an actual staging area is
all of the objects in .git/objects only recorded by the index itself.
Git-stored objects not compressed into pack files could technically be
described as "cached" using the standard definition--they aren't visible
in the working directory. Unfortunately this probably just muddies the
water for all too many users.

So, in summary--the index is real, objects "cached" pending
commit/cleanup/packing are real; any "staging area" is a rhetorical
combination of the two. Given that rhetorical device may not work in all
languages (as Junio mentioned earlier) I don't recommend that we rely on
it.

-- 
-Drew Northup
________________________________________________
"As opposed to vegetable or mineral error?"
-John Pescatore, SANS NewsBites Vol. 12 Num. 59