git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Felipe Contreras <felipe.contreras@gmail.com>
To: Drew Northup <n1xim.email@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>,
	git@vger.kernel.org,
	Piotr Krukowiecki <piotr.krukowiecki.news@gmail.com>,
	Jay Soffian <jaysoffian@gmail.com>, Miles Bader <miles@gnu.org>,
	Jonathan Nieder <jrnieder@gmail.com>,
	Philip Oakley <philipoakley@iee.org>,
	Matthieu Moy <matthieu.moy@grenoble-inp.fr>,
	Ramkumar Ramachandra <artagnon@gmail.com>,
	Scott Chacon <schacon@gmail.com>
Subject: Re: Officially start moving to the term 'staging area'
Date: Thu, 29 Aug 2013 17:10:58 -0500	[thread overview]
Message-ID: <CAMP44s3ABKMAhp_P+QZBWOfjp_wPkqB0A63v6n2mKZv_Ln+qKg@mail.gmail.com> (raw)
In-Reply-To: <CAM9Z-nmXPgfbXezbORb=NCqQuW4p3Dka+bHVdt_n7Sh=jehY7A@mail.gmail.com>

On Thu, Aug 29, 2013 at 4:55 PM, Drew Northup <n1xim.email@gmail.com> wrote:
> On Thu, Aug 29, 2013 at 2:37 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Felipe Contreras <felipe.contreras@gmail.com> 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.

All right, you are the only person (presumably other than Junio) that
thinks "index" is the right name for what high-level users should be
familiar with.

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

The user doesn't need to know the format of the index, or the packs,
in fact, they don't even need to know the index or packs even exist.

All the user needs to know about this is that there's an area where
contents of the next commit are being prepared, and "staging area" is
the best name for that mental area. How that area is actually
implemented (the index) is not relevant to the user.

Everyone agrees on that, except you, and possibly Junio.

-- 
Felipe Contreras

  reply	other threads:[~2013-08-29 22:11 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-29 18:01 Officially start moving to the term 'staging area' Felipe Contreras
2013-08-29 18:09 ` [PATCH 0/2] stage: proper 'stage' command Felipe Contreras
2013-08-29 18:09   ` [PATCH 1/2] Add " Felipe Contreras
2013-08-29 18:38     ` Matthieu Moy
2013-08-29 18:47       ` Felipe Contreras
2013-08-29 18:09   ` [PATCH 2/2] stage: add edit command Felipe Contreras
2013-08-29 18:35     ` Matthieu Moy
2013-08-29 18:42       ` Felipe Contreras
2013-08-29 18:14 ` [PATCH 0/9] Add --stage and --work options Felipe Contreras
2013-08-29 18:14   ` [PATCH 1/9] diff: document --staged Felipe Contreras
2013-08-29 18:14   ` [PATCH 2/9] grep: add --staged option Felipe Contreras
2013-08-29 18:14   ` [PATCH 3/9] rm: " Felipe Contreras
2013-08-29 18:14   ` [PATCH 4/9] stash: add --stage option to save Felipe Contreras
2013-08-29 18:39     ` Matthieu Moy
2013-08-29 18:14   ` [PATCH 5/9] stash: add --stage to pop and apply Felipe Contreras
2013-08-29 18:14   ` [PATCH 6/9] submodule: add --staged options Felipe Contreras
2013-08-29 18:14   ` [PATCH 7/9] apply: add --stage option Felipe Contreras
2013-08-29 18:14   ` [PATCH 8/9] apply: add --work, --no-work options Felipe Contreras
2013-08-29 18:14   ` [PATCH 9/9] completion: update --staged options Felipe Contreras
2013-08-29 18:19 ` [PATCH 0/3] reset: refactor into --stage and --work Felipe Contreras
2013-08-29 18:19   ` [PATCH 1/3] reset: add --stage and --work options Felipe Contreras
     [not found]     ` <CALkWK0=P0xZAk95Jmw9mRUCwPQP7NmVHsuPaWNg+D2v3wP9=-w@mail.gmail.com>
2013-09-08 22:55       ` Felipe Contreras
2013-09-09  0:15         ` Ramkumar Ramachandra
2013-09-09  0:39           ` Felipe Contreras
2013-08-29 18:19   ` [PATCH 2/3] reset: allow --keep with --stage Felipe Contreras
2013-08-29 18:19   ` [PATCH 3/3] completion: update 'git reset' new stage options Felipe Contreras
2013-08-29 18:37 ` Officially start moving to the term 'staging area' Junio C Hamano
2013-08-29 19:57   ` Felipe Contreras
2013-08-30 19:11     ` Felipe Contreras
2013-08-30 20:40       ` Felipe Contreras
2013-08-30 20:42         ` Felipe Contreras
2013-08-30 20:28     ` Felipe Contreras
2013-08-29 21:55   ` Drew Northup
2013-08-29 22:10     ` Felipe Contreras [this message]
2013-09-04  4:45       ` Drew Northup
2013-09-08  2:09         ` Felipe Contreras
2013-08-30  5:16     ` Piotr Krukowiecki
2013-09-04  4:23       ` Drew Northup
2013-09-04  7:13         ` Piotr Krukowiecki
2013-09-04 13:36           ` Drew Northup
2013-09-08  1:27             ` Felipe Contreras
2013-09-08  1:18           ` Felipe Contreras
2013-09-08  1:33         ` Felipe Contreras
2013-09-08  7:49           ` Philip Oakley
2013-09-08  9:27             ` Felipe Contreras
2013-08-29 18:50 ` Matthieu Moy
2013-08-29 18:57   ` Felipe Contreras
2013-08-29 19:15     ` Matthieu Moy
2013-08-29 19:21     ` Matthieu Moy
2013-08-29 20:03     ` René Scharfe
2013-08-29 20:36       ` Felipe Contreras
2013-08-31  7:46         ` René Scharfe
2013-08-31  7:53           ` Felipe Contreras
2013-09-01  3:46           ` David Aguilar
2013-08-29 21:03     ` Matthieu Moy
2013-09-04  6:08 ` William Swanson
2013-09-06 15:45   ` Ping Yin
2013-09-06 17:14     ` Hilco Wijbenga

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=CAMP44s3ABKMAhp_P+QZBWOfjp_wPkqB0A63v6n2mKZv_Ln+qKg@mail.gmail.com \
    --to=felipe.contreras@gmail.com \
    --cc=artagnon@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jaysoffian@gmail.com \
    --cc=jrnieder@gmail.com \
    --cc=matthieu.moy@grenoble-inp.fr \
    --cc=miles@gnu.org \
    --cc=n1xim.email@gmail.com \
    --cc=philipoakley@iee.org \
    --cc=piotr.krukowiecki.news@gmail.com \
    --cc=schacon@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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;
as well as URLs for NNTP newsgroup(s).