All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andreas Krey <a.krey@gmx.de>
To: Karsten Blees <karsten.blees@gmail.com>
Cc: Git List <git@vger.kernel.org>
Subject: Re: [PATCH v2 00/14] Officially start moving to the term 'staging area'
Date: Thu, 24 Oct 2013 10:32:47 +0200	[thread overview]
Message-ID: <20131024083247.GA1705@inner.h.apk.li> (raw)
In-Reply-To: <5268706B.4040303@gmail.com>

On Thu, 24 Oct 2013 02:57:15 +0000, Karsten Blees wrote:
...
> The latter. I don't know about 'broader', but I'll try to summarize _my_ world view:
> 
> (1) Audience matters
> 
> For actual users, we need an accurate model that supports a variety of use cases without falling apart. IMO, a working model is more important than simplicity. Finally, its more important to agree on the actual model than on a vague term that can mean many things (theater stage vs. loading dock...).

Terms almost invariable mean multiple things in different contexts,
and assume new meaning in new fields.

> For potential users / decision makers, we need to describe git's features in unmistakable terms that don't need extra explanation. In this sense, the index / cache / staging area is not a feature in itself but facilitates a variaty of broader features:
> - fine grained commit control (via index (add -i), but also commit -p, commit --amend, cherry-pick, rebase etc.)

The audience will have a hard time understanding what these features
actually do (and how they interact) if we hide the underlying model from
them - they then need to build that model themselves.

And no decision-maker will make the effort to understand either the
operations you mention or the concept of the staging area, unless they
are also users.

...
> An index, as in a library, maps almost perfectly to what the git index is _and_ what we do with it.

No, it doesn't. The git index actually contains the content of the added
files, not just an identity reference. (Unless, maybe, you consider file
sha1s as a reference and not actual content.) The point is that the
index doesn't just contain a mapping from file names to some objects,
but de facto a tree - that will form the next commit.

...
> (3a) Staging area (logistics)
> 
> A staging area, as in (military) logistics / transportation, is about moving physical goods around. You move an item from your stock to the staging area, then onto the truck and finally deliver it to the customer.
> 
> The defining characteristic of a physical good is its physical existence. Each item is uniquely identifiable by a serial number.

Please show me the serial numbers on bullets.

> Problem #1: If an item in the staging area is broken, you fix it directly in the staging area, because that's where it _is_.

That may be true in a physical world, and may not be - you can as well
replace them instead of repairing them in place.

The real problem: You can find some reason why any possible existing
name for this concept isn't correct.

...
> I don't see how a stage (as in a theater) is in any way related to the git index.

It's because the name 'stage (noun)' goes with the verb 'stage'. You
stage a play, or you stage content to be committed. From that, you
may almost call the index just 'stage'.

Andreas

-- 
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800

  reply	other threads:[~2013-10-24  8:39 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-14 22:29 [PATCH v2 14/14] completion: update 'git reset' new stage options Felipe Contreras
2013-10-14 22:29 ` [PATCH v2 04/14] grep: add --staged option Felipe Contreras
2013-10-14 22:29 ` [PATCH v2 07/14] stash: add --stage to pop and apply Felipe Contreras
2013-10-14 22:29 ` [PATCH v2 00/14] Officially start moving to the term 'staging area' Felipe Contreras
2013-10-14 22:51   ` Felipe Contreras
2013-10-17 19:50     ` Junio C Hamano
2013-10-17 21:50       ` Felipe Contreras
2013-10-18  9:46       ` Matthieu Moy
2013-10-18 10:26         ` John Szakmeister
2013-10-18 10:36         ` Felipe Contreras
2013-10-18 11:38       ` Max Horn
2013-10-18 23:28   ` Karsten Blees
2013-10-19  0:41     ` Felipe Contreras
2013-10-19 14:08     ` Philip Oakley
2013-10-24  0:57       ` Karsten Blees
2013-10-24  8:32         ` Andreas Krey [this message]
2013-10-24 23:19         ` Felipe Contreras
2013-10-14 22:29 ` [PATCH v2 10/14] apply: add --work, --no-work options Felipe Contreras
2013-10-14 22:29 ` [PATCH v2 01/14] Add proper 'stage' command Felipe Contreras
2013-10-14 23:06   ` Eric Sunshine
2013-10-14 23:15     ` Felipe Contreras
2013-10-14 22:29 ` [PATCH v2 09/14] apply: add --stage option Felipe Contreras
2013-10-14 22:29 ` [PATCH v2 03/14] diff: document --staged Felipe Contreras
2013-10-14 22:29 ` [PATCH v2 05/14] rm: add --staged option Felipe Contreras
2013-10-14 22:29 ` [PATCH v2 02/14] stage: add edit command Felipe Contreras
2013-10-14 22:29 ` [PATCH v2 13/14] reset: allow --keep with --stage Felipe Contreras
2013-10-14 22:29 ` [PATCH v2 12/14] reset: add --stage and --work options Felipe Contreras
2013-10-14 22:29 ` [PATCH v2 08/14] submodule: add --staged options Felipe Contreras
2013-10-14 22:29 ` [PATCH v2 11/14] completion: update " Felipe Contreras
2013-10-14 22:29 ` [PATCH v2 06/14] stash: add --stage option to save Felipe Contreras

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=20131024083247.GA1705@inner.h.apk.li \
    --to=a.krey@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=karsten.blees@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.