Stefan Beller <sbeller@xxxxxxxxxx> writes: >>> * I think we want to head for consistency, eventually. >>> e.g. commands with no arguments such as tag, branch >>> give a list of their respective domain. >> >> Isn't that a historical mistake we are regretting, though? Only >> after many other operation modes were invented and "create X" proves >> not to be the only primary modes we had to invent "tag -l" and >> "branch -l". Aren't we better off not having "no option means list" >> kind of default? > > listing is not destructive, and I really like to not type a single dash > for some commands. Actually, listing is destructive to the user's cognitive state. I wouldn't be surprised if many people wished that "git branch" did not list (and required "git branch -l" to list) to scroll everything they are looking away but instead showed what the current branch is. >>> Subcommands do not give lists by default, e.g. >>> `git stash clear`, `git remote prune` >>> which are the moral equivalent to >>> `git submodule deinit` just work as they were told, no --switch needed. >> >> I wouldn't say "git rm" should remove everything by extending that >> logic, but I can certainly buy if somebody argues "git submodule >> deinit" is not destructive enough to warrant extra safety. > > `git rm` is a command, not a subcommand though. Yes, it is a command, just like branch and tag you brought up. "git branch -d" is not a command, but a mode of operation. If we did the "mode word" UI [*1*], it would have been a subcommand. And I certainly would not say it should remove everything if there is no argument on the command line. I am not sure where you are going with that though anyway. I think the "safety" is about forcing user to be more explicit when triggering mass destruction, and I do not think it matters if that destruction is done by a first-class subcommand of "git", or subsubcommand. [References] *1* http://thread.gmane.org/gmane.comp.version-control.git/231376/focus=231478 -- 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