Re: Officially start moving to the term 'staging area'

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

 



On Thu, Aug 29, 2013 at 2:37 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Felipe Contreras <felipe.contreras@xxxxxxxxx> writes:
>
>> It has been discussed many times in the past that 'index' is not an
>> appropriate description for what the high-level user does with it, and
>> it has been agreed that 'staging area' is the best term.
>
> "add" is the verb, not "index" (which is a noun that refers
> to the thing that keeps track of what will be written as a tree to
> be committed next).
>
> And it will stay that way.
>
> IIRC, when this was discussed, many non-native speakers had trouble
> with the verb "to stage", not just from i18n/l10n point of view.

I agree with Junio. This effort is better spent making the
documentation clearer and more succinct. The reality is that a user
needs to build a model in their mind of what they are doing which maps
enough (completely is not required) to what is actually going on to
get work done. If the documentation or the instruction is getting in
the way of that in the name of simplifying the presentation then the
presentation is wrong.

We add content snapshots to the index of content (creating
"temporary"--they will be garbage collected eventually if they become
orphans--objects into the store at the same time). We build commits
from those snapshots (in whole or in part, typically only using the
most recent snapshots of new things added to the index) and save those
in the object store with the content and tree objects. Sometimes we
create tag objects to record something special about commits, trees,
and content blobs.

That's the real model (with some rough edges). Explaining what that
has to do with distributed version control is the hard part.

-- 
-Drew Northup
--------------------------------------------------------------
"As opposed to vegetable or mineral error?"
-John Pescatore, SANS NewsBites Vol. 12 Num. 59
--
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]