git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>
To: Felipe Contreras <felipe.contreras@gmail.com>
Cc: git@vger.kernel.org, "Junio C Hamano" <gitster@pobox.com>,
	"Jonathan Nieder" <jrnieder@gmail.com>,
	"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: Sun, 06 May 2012 12:26:48 +0200	[thread overview]
Message-ID: <vpqehqxmwpj.fsf@bauges.imag.fr> (raw)
In-Reply-To: <CAMP44s1qqpTxRvjEH32MNqzUeNhgZ1gB+fu=cgvxnSbMB6oBGA@mail.gmail.com> (Felipe Contreras's message of "Sat, 5 May 2012 15:04:25 +0200")

Felipe Contreras <felipe.contreras@gmail.com> writes:

> Proposal:
>
> Avoid the terms 'cache' and 'index' in favor of 'stage'.

I completely agree that something needs to be done.

But there are at least two points that were raised during the previous
discussions that need to be taken into account:

* Currenly, "index" and "staging area" are not exactly synonyms. When
  used with "git add" and "git commit" (without -a), the index is the
  staging area for the next commit. But when used by "git merge", the
  index is more a "merging area".

* There is currently a distinction in the meaning of --cached and
  --index. See the end of Documentation/gitcli.txt. I think it is good
  to have this distinction, but I agree that the wording of current
  option name is wrong (i.e. without having read gitcli.txt, I don't
  think anyone could have guessed this distinction). Perhaps something
  like --staged-only/--staged-too?

About the name, an alternative to "stage" was suggested earlier:
"precommit". If we were to rewrite Git from scratch, I'd argue in favor
of this one, which is really easy to understand, especially for
non-native (you really need to know what a "commit" is to use Git, and
then infering the meaning of precommit is easy). But we probably have
already a too long history of changing the name, so introducing yet
another one is perhaps counter-productive. I don't know.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

  parent reply	other threads:[~2012-05-06 10:27 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 [this message]
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
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=vpqehqxmwpj.fsf@bauges.imag.fr \
    --to=matthieu.moy@grenoble-inp.fr \
    --cc=felipe.contreras@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jnareb@gmail.com \
    --cc=johannes.schindelin@gmx.de \
    --cc=jrnieder@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).