Re: Consistent terminology: cached/staged/index

From: Felipe Contreras <felipe.contreras@gmail.com>
Date: Feb 27, 2011, 00:16 UTC
Message-ID: <AANLkTimyXciScc5K6ozggMHsy9YmgyOFpy6pgKBEypC9@mail.gmail.com>
In-Reply-To: <20110226215139.GA19176@elie>

On Sat, Feb 26, 2011 at 11:51 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:

Show 8 quoted lines

> These terms you suggest aren't the established ones (as I'm sure you
> know).  Just as with everyday language, there is some resistance to
> moving to new terms that have not been established for a while.  In
> everyday language, many terms gained popularity by
>
>  - appearing in some document that people read for another reason
>  - describing the notion they are meant to describe clearly (or
>   having some other feature that makes them likeable)

There's always resistance, but 1.8 is supposed to contain stuff as "if git was written from scratch". I think this makes sense as one of them.

Show 8 quoted lines

> This is how "staging area" has been gaining popularity, I think ---
> some (out-of-tree) documentation that is good for other reasons uses
> it, and it really does seem to be a clearer term than "index" for
> "place where the next commit is being prepared".  Unfortunately, I do
> not think it is a clearer term than "index" for "the git index, which
> contains stat() information and pointers to blobs that either belong
> in the next commit or are participating in a merge conflict".  So it
> does not seem to justify rewriting everything to use it.

Why should the users care about the stat() information? Or how the merge conflicts are being tracked? That's plumbing, not porcelain.

-- 
Felipe Contreras