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

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

 



On 2007-01-12, Junio C Hamano <junkio@xxxxxxx> wrote:
> "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.

I already proposed it but I like "git refresh". It describes precisely
whats happening - the previous content of the file known to git is
refreshed. AFAIK "update" isn't such a good choice because people from
other VCS would expect something else(think e.g. of cvs update).
>
> 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.
>

Me doesn't really like the new semantics of "git-add", because it does
two seperate things - it adds new files and it refreshes the content of
previously known files. These two are, at least for me, two seperate
operations. And reading "git add" only suggests to me the first - adding
new files.

-Peter

-
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]