Felipe Contreras <felipe.contre...@gmail.com> writes: > It has been discussed many times in the past that 'index' is not an > appropriate description for what the high-level user does with it, and > it has been agreed that 'staging area' is the best term.
Thanks for working on this. No time for a really detailed review, but a few remarks. > The term 'staging area' is more intuitive [...] > > The first step in moving Git towards this term, is first to add --stage > options for every command that uses --index or --cache. These explanations make sense. I think it would be better to put part of it in commit messages, so that future contributors can "git blame" the doc/implem of these --stage and find them (i.e. avoid the misunderstanding that occured with "git stage" command which was proposed for removal). > After adding the new --stage options and making sure no functionality is > lost, they can become the recommended ones in the documentation, > eventually, the old ones get deprecated, and eventually obsoleted. Same: putting this in the commit message would cast in stone that we want to obsolete the old ones. (But that was nice to have this cover-letter) > Moreover, the --stage and --work --work alone sounds weird. At least to me, it does not immediately imply "working tree". It is tempting to call the option --work-tree, but git already has a global option with that name (git --work-tree=foo bar). Perhaps --worktree to limit the confusion? > reset', and after these options are added, the complicated table to > explain the different behaviors between --soft, --mixed, and --hard > becomes so simple it's not needed any more: I didn't understand the table, but yes, the --soft, --mixed, and --hard is terrible, I need to read the doc whenever I do something non-trivial with reset :-(. -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
