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

Re: [1.8.0] use 'stage' term consistently

From
Jonathan Nieder <jrnieder@gmail.com>
Date
May 19, 2012, 06:00 UTC
Message-ID
<20120519060031.GB23799@burratino>
In-Reply-To
<CAHREChgTHZL0sNJ3TkZOL7x4k9x=4GRhrZ6Gm0W+Ai_UnX2FEg@mail.gmail.com>
Hi Mark,
Mark Lodato wrote:
Show 6 quoted lines
> I agree with Felipe that "staging" is the most appropriate term for
> "adding to the index" in git.  As a native English speaker, I have
> never thought of "to stage" as relating to shipping in any way.  To
> me, by far the most common usage is in real estate.  The seller of a
> home "stages" it by setting up furniture and decorations to make the
> home as appealing to prospective buyers as possible.

I think staging a home does not fit very well here, actually. As you said, staging a home is like staging a play, creating an illusion and putting on a production. It is not obvious how this concept would help me understand what it means to add content to the index.

By contrast, if you run an image search for "staging area", you will see examples in all sorts of fields --- shipping, military logistics, data warehousing, disaster relief. It is a familiar, non domain-specific term for native English speakers. In all these fields, staging means to put everything needed in one place before deploying. This matches the concept of a file that tracks the content of the commit being prepared very well.

"aire de rassemblement" doesn't get as many hits from a web search, alas, so I guess the idiom is not as popular in other languages.

For the sake of having a proposal: :)
 - the file representing the content of the next command would still
   be called .git/index and not be renamed
 - adding and removing content to and from the index is "staging a
   change".  Since it is not safe to assume the reader already
   knows what that means, when working on the manual authors should
   try to imagine themselves as a new user and make the text
   unambiguous enough to help such a person.
   For example, the first sentence of the "git add" manual:
	This command updates the index using the current content found in the
	working tree, to prepare the content staged for the next commit.
   should not be changed to:
	This command updates the staging area using ...
   because that just makes it less clear.  Before, it said "the index"
   and I could look in the glossary or the .git directory to at least
   find what file it was talking about.  Afterwards, it is using an
   everyday term and the new user wonders "which staging area?".
   Instead, it would be better to change it to something like:
	This command modifies the content staged for the next commit
	using content found in the working tree.  It typically adds ...
	The "index" file (see gitindex(5)) typically holds a snapshot of
	the content of the working tree, and it is this snapshot that is
	taken as the content of the next commit.  Thus after making any
	changes to the working directory, and before running the commit
	command, you must use the add command to add any new or modified
	files.

Sensible? If so, patches welcome. :) If not, what sort of changes would you like to see instead?

By the way, I don't mean that "the .git/index file will not be renamed" above to be non-negotiable. I didn't get the impression anyone wanted it to be renamed, but if someone does want to rename it to .git/staging-area, then I suppose we could discuss that.

Hope that helps, Jonathan

Previous: Mark LodatoNext: Jonathan Nieder
Message 23 of 34 in “[1.8.0] use 'stage' term consistently”
  1. Felipe ContrerasMay 5, 2012
  2. Philip OakleyMay 5, 2012
  3. Felipe ContrerasMay 5, 2012
  4. Philip OakleyMay 5, 2012
  5. Zbigniew Jędrzejewski-SzmekMay 6, 2012
  6. Jakub NarebskiMay 6, 2012
  7. Matthieu MoyMay 6, 2012
  8. Felipe ContrerasMay 6, 2012
  9. Jakub NarebskiMay 6, 2012
  10. Junio C HamanoMay 8, 2012
  11. Felipe ContrerasMay 6, 2012
  12. Matthieu MoyMay 6, 2012
  13. Felipe ContrerasMay 6, 2012
  14. Ævar Arnfjörð BjarmasonMay 6, 2012
  15. Junio C HamanoMay 7, 2012
  16. Ævar Arnfjörð BjarmasonMay 7, 2012
  17. Junio C HamanoMay 8, 2012
  18. Ævar Arnfjörð BjarmasonMay 8, 2012
  19. Junio C HamanoMay 8, 2012
  20. Felipe ContrerasMay 9, 2012
  21. Matthieu MoyMay 9, 2012
  22. Mark LodatoMay 19, 2012
  23. Jonathan NiederMay 19, 2012
  24. Jonathan NiederMay 19, 2012
  25. Felipe ContrerasMay 20, 2012
  26. Jonathan NiederMay 20, 2012
  27. Philip OakleyMay 19, 2012
  28. Felipe ContrerasMay 20, 2012
  29. Jonathan NiederMay 20, 2012
  30. Junio C HamanoMay 20, 2012
  31. Felipe ContrerasMay 21, 2012
  32. Jonathan NiederMay 21, 2012
  33. Thiago FarinaMay 18, 2012
  34. Sebastien DoucheMay 8, 2012

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.