Re: [1.8.0] use 'stage' term consistently
- From
Matthieu Moy <matthieu.moy@grenoble-inp.fr>
- Date
- May 6, 2012, 10:26 UTC
- Message-ID
- <vpqehqxmwpj.fsf@bauges.imag.fr>
- In-Reply-To
- <CAMP44s1qqpTxRvjEH32MNqzUeNhgZ1gB+fu=cgvxnSbMB6oBGA@mail.gmail.com>
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/