git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jonathan Nieder <jrnieder@gmail.com>
To: Mark Lodato <lodatom@gmail.com>
Cc: "Junio C Hamano" <gitster@pobox.com>,
	"Ævar Arnfjörð" <avarab@gmail.com>,
	"Felipe Contreras" <felipe.contreras@gmail.com>,
	"Matthieu Moy" <Matthieu.Moy@grenoble-inp.fr>,
	git@vger.kernel.org, "Jeff King" <peff@peff.net>,
	"Scott Chacon" <schacon@gmail.com>,
	"Paolo Ciarrocchi" <paolo.ciarrocchi@gmail.com>,
	"Jakub Narębski" <jnareb@gmail.com>,
	"Johannes Schindelin" <johannes.schindelin@gmx.de>,
	"Piotr Krukowiecki" <piotr.krukowiecki.news@gmail.com>
Subject: Re: [1.8.0] use 'stage' term consistently
Date: Sat, 19 May 2012 01:00:32 -0500	[thread overview]
Message-ID: <20120519060031.GB23799@burratino> (raw)
In-Reply-To: <CAHREChgTHZL0sNJ3TkZOL7x4k9x=4GRhrZ6Gm0W+Ai_UnX2FEg@mail.gmail.com>

Hi Mark,

Mark Lodato wrote:

> 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

  reply	other threads:[~2012-05-19  6:01 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-05 13:04 [1.8.0] use 'stage' term consistently Felipe Contreras
2012-05-05 16:52 ` Philip Oakley
2012-05-05 17:30   ` Felipe Contreras
2012-05-05 19:53     ` Philip Oakley
2012-05-06  9:53 ` Zbigniew Jędrzejewski-Szmek
2012-05-06 10:21 ` Jakub Narebski
2012-05-06 10:39   ` Matthieu Moy
2012-05-06 20:15     ` Felipe Contreras
2012-05-06 21:21       ` Jakub Narebski
2012-05-08  3:51     ` Junio C Hamano
2012-05-06 21:09   ` Felipe Contreras
2012-05-06 10:26 ` Matthieu Moy
2012-05-06 21:16   ` Felipe Contreras
2012-05-06 21:30     ` Ævar Arnfjörð Bjarmason
2012-05-07 17:52       ` Junio C Hamano
2012-05-07 20:05         ` Ævar Arnfjörð Bjarmason
2012-05-08  4:06           ` Junio C Hamano
2012-05-08  8:55             ` Ævar Arnfjörð Bjarmason
2012-05-08 14:53               ` Junio C Hamano
2012-05-09 13:10             ` Felipe Contreras
2012-05-09 17:25               ` Matthieu Moy
2012-05-19  0:50         ` Mark Lodato
2012-05-19  6:00           ` Jonathan Nieder [this message]
2012-05-19  6:32             ` Jonathan Nieder
2012-05-20 12:04               ` Felipe Contreras
2012-05-20 18:06                 ` Jonathan Nieder
2012-05-19 10:14             ` Philip Oakley
2012-05-20 11:49             ` Felipe Contreras
2012-05-20 17:58               ` Jonathan Nieder
2012-05-20 21:11             ` Junio C Hamano
2012-05-21  1:12               ` Felipe Contreras
2012-05-21  1:32                 ` Jonathan Nieder
2012-05-18 20:34   ` Thiago Farina
2012-05-08 14:01 ` Sebastien Douche

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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120519060031.GB23799@burratino \
    --to=jrnieder@gmail.com \
    --cc=Matthieu.Moy@grenoble-inp.fr \
    --cc=avarab@gmail.com \
    --cc=felipe.contreras@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jnareb@gmail.com \
    --cc=johannes.schindelin@gmx.de \
    --cc=lodatom@gmail.com \
    --cc=paolo.ciarrocchi@gmail.com \
    --cc=peff@peff.net \
    --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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).