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

[Stefan Beller <sbeller@google.com>]

On Tue, May 3, 2016 at 2:32 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Stefan Beller <sbeller@google.com> 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.

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`)

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