git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Felipe Contreras <felipe.contreras@gmail.com>
To: Drew Northup <drew.northup@maine.edu>
Cc: Pete Harlan <pgit@pcharlan.com>,
	Junio C Hamano <gitster@pobox.com>,
	Jonathan Nieder <jrnieder@gmail.com>,
	Piotr Krukowiecki <piotr.krukowiecki.news@gmail.com>,
	git@vger.kernel.org
Subject: Re: Consistent terminology: cached/staged/index
Date: Sat, 26 Feb 2011 22:36:39 +0200	[thread overview]
Message-ID: <AANLkTincNdUQ=736=M2Oei4LF0pR0c2T7r=bWJE3RFCu@mail.gmail.com> (raw)
In-Reply-To: <1297897887.24521.57.camel@drew-northup.unet.maine.edu>

On Thu, Feb 17, 2011 at 1:11 AM, Drew Northup <drew.northup@maine.edu> wrote:
>
> On Sun, 2011-02-13 at 19:09 -0800, Pete Harlan wrote:
>> On 02/13/2011 02:58 PM, Junio C Hamano wrote:
>> >> --staged
>> >> ~~~~~~~~
>> >> diff takes --staged, but that is only to support some people's habits.
>> > The term "stage" comes from "staging area", a term people used to explain
>> > the concept of the index by saying "The index holds set of contents to be
>> > made into the next commit; it is _like_ the staging area".
>> >
>> > My feeling is that "to stage" is primarily used, outside "git" circle, as
>> > a logistics term.  If you find it easier to visualize the concept of the
>> > index with "staging area" ("an area where troops and equipment in transit
>> > are assembled before a military operation", you may find it easier to say
>> > "stage this path ('git add path')", instead of "adding to the set of
>> > contents...".
>>
>> FWIW, when teaching Git I have found that users immediately understand
>> "staging area", while "index" and "cache" confuse them.
>>
>> "Index" means to them a numerical index into a data structure.
>> "Cache" is a local copy of something that exists remotely.  Neither
>> word describes the concept correctly from a user's perspective.
>
> According to the dictionary (actually, more than one) "cache" is a
> hidden storage space. I'm pretty sure that's the sense most global and
> therefore most appropriate to thinking about Git. (It certainly
> describes correctly what web browser cache and on-CPU cache is doing.)
> One would only think the definition you gave applied if they didn't know
> that squirrels "cache" nuts. I don't think that the problem is the
> idiom.

Not really. If a squirrel "caches" nuts, it means a squirrel is
putting them in a hidden place to save them for future use. So, in the
future, if said squirrel wants a nut, it doesn't have to look for it
in the trees, just go to the cache. So the cache makes it easier to
access whatever your want.

IOW; if you don't cache something, you would have more trouble getting
it, but you still can.

That's not what Git is doing. Git is not putting changes in a place so
the can be more easily accessed in the future. It is using a temporary
device that allows the commit to be built through an extended period
of time. It's not a cache.

>> I learned long ago to type "index" and "cached", but when talking (and
>> thinking) about Git I find "the staging area" gets the point across
>> very clearly and moves Git from interesting techie-tool to
>> world-dominating SCM territory.  I'm surprised that that experience
>> isn't universal.
>
> Perhaps that helps you associate it with other SCM/VCS software, but it
> didn't help me. When I realized that the "index" is called that BECAUSE
> IT IS AN INDEX (of content/data states for a pending commit operation)
> the sky cleared and the sun came out.

That's not an index. An index is a guide of pointers to something
else. It allows you to find whatever you are looking for by looking in
small table of pointers instead of looking through all the samples.

IOW; if you don't index something, you would have more trouble finding
it, but you still can.

That's not what Git is doing.

> In all reality the closest thing Git has to an actual staging area is
> all of the objects in .git/objects only recorded by the index itself.
> Git-stored objects not compressed into pack files could technically be
> described as "cached" using the standard definition--they aren't visible
> in the working directory. Unfortunately this probably just muddies the
> water for all too many users.

That's irrelevant. You can implement the same functionality in many
other ways. How it is implement doesn't matter, what matters is what
the user experiences.

> So, in summary--the index is real, objects "cached" pending
> commit/cleanup/packing are real; any "staging area" is a rhetorical
> combination of the two. Given that rhetorical device may not work in all
> languages (as Junio mentioned earlier) I don't recommend that we rely on
> it.

Branches and tags are "rthetorical" devices as well. But behind scenes
they are just refs. Shall we disregard 'branch' and 'tag'?

No. What Git does behind scenes is irrelevant to the user. What
matters is what the device does, not how it is implemented; the
implementation might change. "Stage" is the perfect word; both verb
and a noun that express a temporary space where things are prepared
for their final form.

-- 
Felipe Contreras

  reply	other threads:[~2011-02-26 20:36 UTC|newest]

Thread overview: 65+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-13 19:20 Piotr Krukowiecki
2011-02-13 19:37 ` Jonathan Nieder
2011-02-13 22:58   ` Junio C Hamano
2011-02-14  2:05     ` Miles Bader
2011-02-14  5:57       ` Junio C Hamano
2011-02-14  6:27         ` Miles Bader
2011-02-14  6:59           ` Johannes Sixt
2011-02-14  7:07             ` Miles Bader
2011-02-14 10:42               ` Michael J Gruber
2011-02-14 11:04                 ` Miles Bader
2011-02-14 17:12                   ` Junio C Hamano
2011-02-14 22:07                     ` Miles Bader
2011-02-14 22:59                       ` Junio C Hamano
2011-02-14 23:47                         ` Miles Bader
2011-02-15  0:12                           ` Junio C Hamano
2011-02-14 13:14                 ` Nguyen Thai Ngoc Duy
2011-02-14 13:43                   ` Michael J Gruber
2011-02-14 13:57                     ` Nguyen Thai Ngoc Duy
2011-02-14 14:17                     ` Felipe Contreras
2011-02-14 14:21                       ` Nguyen Thai Ngoc Duy
2011-02-14 14:40                         ` Jakub Narebski
2011-02-14 15:24                       ` Michael J Gruber
2011-02-14 16:00                         ` Felipe Contreras
2011-02-14 16:04                           ` Michael J Gruber
2011-02-14 16:27                             ` Felipe Contreras
2011-02-14  3:09     ` Pete Harlan
2011-02-16 23:11       ` Drew Northup
2011-02-26 20:36         ` Felipe Contreras [this message]
2011-02-27 15:30           ` Drew Northup
2011-02-27 21:16       ` Aghiles
2011-02-28 20:53         ` Drew Northup
2011-02-14 22:32     ` Piotr Krukowiecki
2011-02-14 23:19       ` Jonathan Nieder
2011-02-15  8:29         ` Pete Harlan
2011-02-15  9:00           ` Jonathan Nieder
2011-02-15 18:15         ` Piotr Krukowiecki
2011-02-15 18:38           ` Jonathan Nieder
2011-02-26 21:09         ` Felipe Contreras
2011-02-26 21:51           ` Jonathan Nieder
2011-02-27  0:01             ` Miles Bader
2011-02-27  0:16             ` Felipe Contreras
2011-02-27  0:46               ` Jonathan Nieder
2011-02-27  8:15               ` Junio C Hamano
2011-02-27  8:43           ` Jeff King
2011-02-27  9:21             ` Miles Bader
2011-02-27 22:28               ` Jon Seymour
2011-02-27 23:57                 ` Junio C Hamano
2011-02-28  9:38                   ` Michael J Gruber
2011-02-27 15:34             ` Drew Northup
2011-02-28 23:03               ` Jeff King
2011-03-01  9:11                 ` David
2011-03-01  9:15                   ` Matthieu Moy
2011-03-01  9:32                     ` Alexei Sholik
2011-03-01 17:02                       ` Drew Northup
2011-03-01 17:30                         ` Alexei Sholik
2011-03-01 17:41                           ` Drew Northup
2011-03-01  9:27                   ` Alexey Feldgendler
2011-03-01 16:46                     ` Drew Northup
2011-03-04 17:18                       ` Felipe Contreras
2011-03-05  4:53                         ` Miles Bader
2011-03-05  5:00                           ` Jonathan Nieder
2011-03-06 12:44                           ` Drew Northup
     [not found]               ` <878466.93199.1298934204331.JavaMail.trustmail@mail1.terreactive.ch>
2011-03-01  8:43                 ` Victor Engmark
2011-02-27 18:46           ` Phil Hord
2011-03-01 10:29 ` Jonathan Nieder

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='AANLkTincNdUQ=736=M2Oei4LF0pR0c2T7r=bWJE3RFCu@mail.gmail.com' \
    --to=felipe.contreras@gmail.com \
    --cc=drew.northup@maine.edu \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jrnieder@gmail.com \
    --cc=pgit@pcharlan.com \
    --cc=piotr.krukowiecki.news@gmail.com \
    --subject='Re: Consistent terminology: cached/staged/index' \
    /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

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