> * The `--cached` option is used to ask a command that > usually works on files in the working tree to *only* work > with the index. For example, `git grep`, when used > without a commit to specify from which commit to look for > strings in, usually works on files in the working tree, > but with the `--cached` option, it looks for strings in > the index. > > * The `--index` option is used to ask a command that > usually works on files in the working tree to *also* > affect the index. For example, `git stash apply` usually > merges changes recorded in a stash to the working tree, > but with the `--index` option, it also merges changes to > the index as well. Doesn't this just offer opportunity for two new options? E.g., --staged and --also-staged or --include-staged or something? In the current form, these two options provide a variation of the same concept, using completely different option names (which could lead people to think that they're really the same option, just inconsistently implemented). So, regardless of changing over to --staged, I guess these two options could be made more consistent (though sticking to the "index" terminology is tricky, since that would require --cached to be become --index and --index to become --include--index, which throws away backward compatibility...). FWIW, I do rather like the "staging area" concept, since I feel it accurately describes its use (or at least the most common use of the staging area). Gr. Matthijs
Attachment:
signature.asc
Description: Digital signature