Re: friendlier names

> David Abrahams <dave@boostpro.com> wrote:
>> 
>> For example, why couldn't the "index" be called the "stage" instead?
>> That, along with knowing that "git add" was a synonym for "git stage"
>> would have flattened the learning curve considerably for me.
>
> Historical reasons...
>
> Waaay back the "index" was an index of the files git knows about in
> your working directory.  It made sense to call it an index, as like
> a book index it was a full listing of what's here, sorted by name.
>
> That's pre-1.0 days.  Like the very first version Linus ever
> released.  Aka commit e83c5163316f89bfbde7d9ab23ca2e25604af290.

> Much, much later, over many months, the index morphed into what
> you see today, which is a "staging area", accessed by "git add".
>
> This was all incremental, in small parts.  Nobody set out to
> design a "staging area" or to have "staging actions".  Back
> when it was really the index you updated it with a tool called
> git-update-index.  Adding new files required the --add flag.
>
> People found --add annoying, so they wrote "git add" as a
> wrapper around it.  But modified existing files still had
> to be updated with git-update-index.  Then someone pointed
> out that add of an existing file and add of a new file are
> similiar enough that they should just be the same command,
> "git add".
>
> Only late last October at the GitTogether did we start to talk about
> creating a command called "git stage", because people have started to
> realize we seem to call it a "staging area" as we train newcomers...

> The tools are _all_ slowly evolved over time.  Nothing in git
> was ever set out from the beginning as a "this is what we are
> going to do".  The only part of Git that is like that is the core
> data structure on disk for the object store.  That hasn't changed
> since Linus switched from SHA1(COMPRESS(data)) to SHA1(data) for
> the object naming algorithm, and even that was done in the first
> couple of weeks.