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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



"Chris Riddoch" <riddochc@xxxxxxxxx> 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.

> First, specifying extra files after 'git commit' bypasses the index.

Which I happen to think is a misfeature.

> If I remove foo.txt, and want to make a new commit reflecting only
> that removal, 

If you try latest 'git status' in that situation, it would say
foo.txt is deleted but not updated and suggests to use git-add or
git-rm to include it in the commit you are creating.

> ...  But then I need to remember to use 'git add'
> to keep track of most changes in the index, new files and edits alike.

"git commit -a" is your friend.  I think new people should be
taught that form first, and then "git status" output, and then
what "git status" suggests them to do (which is "git add" or
"git rm").


-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]