Re: [1.8.0] use 'stage' term consistently

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Felipe Contreras <felipe.contreras@xxxxxxxxx> 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/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]