From: Junio C Hamano <junkio@cox•net>
To: "Chris Riddoch" <riddochc@gmail•com>
Cc: git@vger•kernel.org
Subject: Re: Importing from tarballs; add, rm, update-index?
Date: Fri, 12 Jan 2007 10:47:56 -0800 [thread overview]
Message-ID: <7virfct737.fsf@assigned-by-dhcp.cox.net> (raw)
In-Reply-To: <6efbd9b70701120541n5dc4d0e1va50ae96543d8c80@mail.gmail.com> (Chris Riddoch's message of "Fri, 12 Jan 2007 06:41:21 -0700")
"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.
> 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").
next prev parent reply other threads:[~2007-01-12 18:48 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-12 13:41 Importing from tarballs; add, rm, update-index? Chris Riddoch
2007-01-12 14:09 ` Horst H. von Brand
2007-01-12 14:39 ` Johannes Sixt
2007-01-12 15:39 ` Horst H. von Brand
2007-01-12 14:40 ` Morten Welinder
2007-01-12 18:47 ` Junio C Hamano [this message]
2007-01-12 19:11 ` Peter Baumann
2007-01-12 19:43 ` Junio C Hamano
2007-01-12 21:04 ` Peter Baumann
2007-01-13 0:48 ` Junio C Hamano
2007-01-13 9:33 ` Peter Baumann
2007-01-13 11:17 ` Johannes Schindelin
2007-01-13 16:19 ` Peter Baumann
2007-01-13 16:27 ` Julian Phillips
2007-01-13 18:01 ` Junio C Hamano
2007-01-13 16:09 ` Carl Worth
2007-01-13 16:45 ` Brian Gernhardt
2007-01-13 16:48 ` Peter Baumann
2007-01-13 18:54 ` Nicolas Pitre
2007-01-13 19:32 ` Carl Worth
2007-01-13 20:25 ` Junio C Hamano
2007-01-13 20:29 ` Nicolas Pitre
2007-01-13 6:36 ` Brian Gernhardt
2007-01-13 9:36 ` Peter Baumann
2007-01-13 16:31 ` Brian Gernhardt
2007-01-13 18:15 ` Alan Chandler
2007-01-13 19:31 ` Brian Gernhardt
2007-01-13 20:34 ` Shawn O. Pearce
2007-01-14 12:42 ` Johannes Schindelin
2007-01-14 22:42 ` Shawn O. Pearce
2007-01-14 23:49 ` Horst H. von Brand
2007-01-15 1:06 ` Junio C Hamano
2007-01-15 1:12 ` Shawn O. Pearce
2007-01-15 22:46 ` Daniel Barkalow
2007-01-16 0:34 ` Horst H. von Brand
2007-01-16 3:35 ` Daniel Barkalow
2007-01-16 12:12 ` Christian MICHON
2007-01-16 0:51 ` Jakub Narebski
2007-01-13 21:41 ` Horst H. von Brand
2007-01-13 21:47 ` Shawn O. Pearce
2007-01-13 22:04 ` Horst H. von Brand
2007-01-12 19:34 ` Carl Worth
2007-01-12 23:28 ` Johannes Schindelin
2007-01-13 0:01 ` Junio C Hamano
2007-01-12 20:20 ` Jakub Narebski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7virfct737.fsf@assigned-by-dhcp.cox.net \
--to=junkio@cox$(echo .)net \
--cc=git@vger$(echo .)kernel.org \
--cc=riddochc@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox