Re: Importing from tarballs; add, rm, update-index?

> "Chris Riddoch" <riddochc@gmail.com> writes:
>
>> I suggest calling it something like update-index.  ;)
>
> Exactly.
>
> People new to git need to learn that the next commit is prepared
> not in the working tree but in a separate entity (staging area),
> and there are ways to update what it consists of.  If that
> concept is new for people coming from other SCM, renaming
> "index" to "staging area" only reduces potential confusion
> (because "index" is too generic word that can mean anything) --
> it does not remove the need to learn the new concept.
>
> And we have called that staging area "the index", and the act of
> updating what it consists of has been called "updating the
> index" for a long time.  The primary command to do so has been
> "git-update-index" plumbing, but we added some sugarcoating and
> now "git-add" and "git-rm" (also "git-merge", "git-am" and
> friends "updates the index" for automatable cases) are two most
> visible ways for the users.
>
> The logical name for the operation, if we _were_ to have only
> one command for "updating the index", is "git-update" or
> "git-update-index".  I do not have anything against "git stage"
> but I simply do not see the point, other than "git update" would
> imply something entirely different to people coming from other
> SCM so we would want to avoid the word, and "git update-index"
> is too long to type every day.

>
> In any case, there are valid reasons that update-index has --add
> and --remove options to force callers to specifically say "Yes I
> know I am talking about unusual things, please".  If we _were_
> to do a single command (be it "git-update" or "git-stage"), it
> needs the same --add/--remove safety, which makes "it's too long
> to type every day -- let's have a single Porcelain-ish" argument
> somewhat moot.  We can have "git-add" and "git-rm" instead.
>
> And indeed we do.  That's where we currently stand.
>