From: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>
To: Junio C Hamano <gitster@pobox.com>
Cc: Felipe Contreras <felipe.contreras@gmail.com>,
git@vger.kernel.org,
Piotr Krukowiecki <piotr.krukowiecki.news@gmail.com>,
Jay Soffian <jaysoffian@gmail.com>,
Jonathan Nieder <jrnieder@gmail.com>,
Philip Oakley <philipoakley@iee.org>,
William Swanson <swansontec@gmail.com>,
Ping Yin <pkufranky@gmail.com>,
Hilco Wijbenga <hilco.wijbenga@gmail.com>
Subject: Re: [PATCH v2 00/14] Officially start moving to the term 'staging area'
Date: Fri, 18 Oct 2013 11:46:12 +0200 [thread overview]
Message-ID: <vpqbo2m7vyz.fsf@anie.imag.fr> (raw)
In-Reply-To: <xmqqwqlbznfp.fsf@gitster.dls.corp.google.com> (Junio C. Hamano's message of "Thu, 17 Oct 2013 12:50:50 -0700")
I'm lacking time to read and answer in detail, sorry.
Junio C Hamano <gitster@pobox.com> writes:
> "It must be done" is different from "any change is good, as long as
> it introduces more instances of word 'stage'".
I agree. Something must be done, at least to remove the cache Vs index
confusion. I'm not sure exactly what's best, and we should agree where
to go before going there. The previous attempts to introduce more
"stage" in Git's command-line (e.g. the "git stage" alias) introduced
more confusion than anything else.
> The phrase "staging area" is not an everyday phrase or common CS
> lingo, and that unfortunately makes it a suboptimal choice of words
> especially to those of us, to whom a large portion of their exposure
> to the English language is through the command words we use when we
> talk to our computers.
I do not think being understandable immediately by non-native is so
important actually. To me as a french, "commit" makes no sense as an
english word to describe what "git commit" does, but it's OK as I never
really translate it. Even fr.po translates "a commit" by "un commit".
That said, having something that immediately makes sense to a non-native
is obviously a good point.
Another proposal which I liked BTW was to use the word "precommit".
Short, and easily understood as the place where the next commit is
prepared.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
next prev parent reply other threads:[~2013-10-18 9:46 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 [this message]
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
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=vpqbo2m7vyz.fsf@anie.imag.fr \
--to=matthieu.moy@grenoble-inp.fr \
--cc=felipe.contreras@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=hilco.wijbenga@gmail.com \
--cc=jaysoffian@gmail.com \
--cc=jrnieder@gmail.com \
--cc=philipoakley@iee.org \
--cc=piotr.krukowiecki.news@gmail.com \
--cc=pkufranky@gmail.com \
--cc=swansontec@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.