Re: friendlier names

[Jakub Narebski <jnareb@gmail.com>]

Junio C Hamano <gitster@pobox.com> writes:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
>> 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...

[...]
> The way to update the cache was called "update-cache" then "update-index".
> Because it usually is much rare to actually add a new entry to the index
> than updating an existing entry in the index, the command had a safeguard
> against "update-cache a-newfile" without explicit request from the user to
> say "oh by the way I know I am adding new entries".  "git add" came much
> later to give you a shorthand for "update-index --add".  Updating existing
> entries in the index was still done with "update-index".
> 
> Later Nico taught (after much discussion) "git add" to also serve as
> "update-index" for existing entries in the index.
> 
> We could have called it "git update-index" when we did that switch-over,
> because the operation is exactly that --- updating the index.
> 
> But the name somehow stuck.
[...]

It is a bit of pity that "git add" was overloaded to also add new
contents and not only add new file (and its contents!), instead of
having new command "git stage" to be porcelain version of 
"git update-index" porcelain.  And perhaps "git resolved" to only
mark resolved entries (so e.g. "git resolved ." would not add new
files, nor add new contents of files which were not in conflict).

Now we have to explain that "git add" adds new contents... OTOH
it is perhaps good idea to emphasize differences between Git and
other lesser^W SCMs. ;-)  And introduce "git add -N"... 

-- 
Jakub Narebski
Poland
ShadeHawk on #git