On Fri, Apr 12, 2019 at 12:14 PM Junio C Hamano <gits...@pobox.com> wrote: > > - git-rm learns about --staged as an alias of --cached (in fact it's > > more the other way around). This is to keep suggestions consistent > > because we tell people to do "git foo --staged" everywhere. > > I am not sure 100% about this one. If "--staged" is only about > updating the index without touching the working tree, then existing > "--cached" is already serving its purpose and there is no need to > add yet another.
It's so we suggest the same option name in "git status" instead of - git add/rm/retore <paths> - git restore [--source] --staged <paths> - git rm --cached <paths> It's in the name of consistency but perhaps it's just not worth it? It could also be seen as the continuation of adding --staged [1] [1] https://public-inbox.org/git/1225296936-1357-1-git-send-email-dsymo...@gmail.com/ > Why did we need it for "restore-paths" in the > first place? Is it because the target of restoring can be one of > the three (index+working-tree, index-only, or working-tree only), > not just the traditional two (index+working-tree that is signalled > by "--index", and index-only that is signalled by "--cached")? Yes. > I think it would make sense to introduce --staged to "git rm", if we > teach the third target (i.e. "working-tree only") to the command, > but otherwise, I am not sure if it would help reducing conflusion. I could add that. "git rm --worktree" then is almost like "rm" except that only tracked paths are affected. The default target of "git rm" is still "both worktree and index" though. I don't think we can ever change that (e.g. to match "git restore" which defaults to worktree only) -- Duy
