Re: [RFC] git-add update with all-0 object

From: Daniel Barkalow <barkalow@iabervon.org>
Date: Dec 1, 2006, 08:10 UTC
Message-ID: <Pine.LNX.4.64.0612010223010.20138@iabervon.org>
In-Reply-To: <20061201045727.GA22622@thunk.org>

On Thu, 30 Nov 2006, Theodore Tso wrote:

Show 25 quoted lines

> By the way, after thinking about this for a while, part of the problem
> is that the name "index" really sucks.  Which is perhaps why Linus is
> now trying to stop us from actually using the term "index" in these
> discussions.  :-)    If we called it a "staging area", as our Great
> Leader has suggested, I think it would be a lot easier for novice
> users to understand.    Consider what is in the git man page:
> 
> 	The index is a simple binary file, which contains an efficient
> 	representation of a virtual directory content at some random
> 	time.  It does so by a simple array that associates a set of
> 	names, dates, permissions and content (aka "blob") objects
> 	together. The cache is always kept ordered by name, and names
> 	are unique (with a few very specific rules) at any point in
> 	time, but the cache has no long-term meaning, and can be
> 	partially updated at any time.....
> 
> 	In particular, the index file can have the representation of
> 	an intermediate tree that has not yet been instantiated. So
> 	the index can be thought of as a write-back cache, which can
> 	contain dirty information that has not yet been written back
> 	to the backing store.
> 
> For a kernel programmer, this might not be understandable --- but for
> your typical application programmer, this is enough to cause him or
> her to conclude that git is simply not meant for use by mere mortals.

My position on this subject is that "index" is a good name, but that description is a terrible description, and "index" is a word that needs a good description in context. If we just said up front:

 Git's "index" is a staging area that you use to prepare commits. It maps 
 filenames to content. It allows git to remember changes you want to put 
 into the next commit while you do more work. For normal commits, it is 
 not necessary to use the index, but it is very helpful for complicated 
 commits, because it lets you focus on the part you're still working on 
 while git remembers the part you're done with.

I think people would get it. (If it were called the "cache" still, it would be hopeless, because "cache" implies false things; "index" doesn't imply anything initially.)

Of course, we'd still have to disabuse people of the notion that the index can store the information "there's nothing at this path yet, but I'm interested in it", because that's a piece of information people often know before a file is ready, and think git would be able to remember in a staging area.

	-Daniel