Re: [PATCH 0/3] preparatory patches for the submodule groups

Stefan Beller [off-list ref] writes:

quoted

quoted

* 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.

quoted

quoted

   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