git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH v2 00/14] Officially start moving to the term 'staging area'

From
Andreas Krey <a.krey@gmx.de>
Date
Oct 24, 2013, 08:32 UTC
Message-ID
<20131024083247.GA1705@inner.h.apk.li>
In-Reply-To
<5268706B.4040303@gmail.com>

On Thu, 24 Oct 2013 02:57:15 +0000, Karsten Blees wrote: ...

Show 5 quoted lines
> 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.

...
Show 5 quoted lines
> (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
Previous: Karsten BleesNext: Felipe Contreras
Message 16 of 30 in “completion: update 'git reset' new stage options”
  1. 14/14 completion: update 'git reset' new stage optionsFelipe Contreras, Oct 14, 2013
  2. 04/14 grep: add --staged optionFelipe Contreras, Oct 14, 2013
  3. 07/14 stash: add --stage to pop and applyFelipe Contreras, Oct 14, 2013
  4. 00/14 Officially start moving to the term 'staging area'Felipe Contreras, Oct 14, 2013
  5. Felipe ContrerasOct 14, 2013
  6. Junio C HamanoOct 17, 2013
  7. Felipe ContrerasOct 17, 2013
  8. Matthieu MoyOct 18, 2013
  9. John SzakmeisterOct 18, 2013
  10. Felipe ContrerasOct 18, 2013
  11. Max HornOct 18, 2013
  12. Karsten BleesOct 18, 2013
  13. Felipe ContrerasOct 19, 2013
  14. Philip OakleyOct 19, 2013
  15. Karsten BleesOct 24, 2013
  16. Andreas KreyOct 24, 2013
  17. Felipe ContrerasOct 24, 2013
  18. 10/14 apply: add --work, --no-work optionsFelipe Contreras, Oct 14, 2013
  19. 01/14 Add proper 'stage' commandFelipe Contreras, Oct 14, 2013
  20. Eric SunshineOct 14, 2013
  21. Felipe ContrerasOct 14, 2013
  22. 09/14 apply: add --stage optionFelipe Contreras, Oct 14, 2013
  23. 03/14 diff: document --stagedFelipe Contreras, Oct 14, 2013
  24. 05/14 rm: add --staged optionFelipe Contreras, Oct 14, 2013
  25. 02/14 stage: add edit commandFelipe Contreras, Oct 14, 2013
  26. 13/14 reset: allow --keep with --stageFelipe Contreras, Oct 14, 2013
  27. 12/14 reset: add --stage and --work optionsFelipe Contreras, Oct 14, 2013
  28. 08/14 submodule: add --staged optionsFelipe Contreras, Oct 14, 2013
  29. 11/14 completion: update --staged optionsFelipe Contreras, Oct 14, 2013
  30. 06/14 stash: add --stage option to saveFelipe Contreras, Oct 14, 2013

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.