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
On Tue, May 3, 2016 at 2:32 PM, Junio C Hamano [off-list ref] wrote:
Stefan Beller [off-list ref] writes:
quoted
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.
Oh! I see.
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.
Isn't that yet another more specialized mode of operation?
The difference being that showing the current branch is less lines of output
than showing all branches. (listing the branches could also be done similar
as `ls` lists files instead of `ls -1`)
quoted
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.
Right.
Another point of confusion is that the `submodule deinit` case
expects a path spec unlike all the other examples and path specs
have the notion for specifying "all of them" in different contexts, i.e.
'*' or '.' are valid "all path specs" in other programs.
We do not have a strong history for such "all of them" specifiers for
branches. (Well we could do a git branch -d refs/heads/* but these
are files actually, so we'd think of * as a natural character to do so)
There are no notions for "all of the stashes" (i.e. `git stash clear`
would be weird if it expected a '*'.
I think '--all' is the right thing to do here then.
I am not sure where you are going with that though anyway.
I am trying to asses the users expectations on when you expect
a "safety" feature and when to expect the operation to perform.
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.
Ok. I thought it mattered a bit as a subsubcommand is already more
explicit than a command. Compare `git stash clear` to the
fictional `git clear` command. I would expect a `git clear`
to not delete critical things without arguments. Maybe some minor things
or internal things like garbage collection.
`clear` sounding similar to `clean`, we could have a "submodule.requireForce"
similar to clean.requireForce which would change the behavior of
submodule deinit and defaults to the safe version. (I do not know the
history of clean.requireForce but that sounds like it is a safety measure
added once people complained about having no safety default.)
But this discussion strengthens my opinion that we should just have a switch
for deinit.
Thanks,
Stefan
[References]
*1* http://thread.gmane.org/gmane.comp.version-control.git/231376/focus=231478