Re: [PATCH 0/2] Parsing a subcommand using parse-options

Ramkumar Ramachandra <artagnon@gmail.com> writes:

Contrasting this with "git tag --list", one uses subcommand verb while the other uses operating mode option and one could say they are inconsistent.

But it does not bother me that much, and for a good reason other than inertia.

When a command whose primary purpose is very clear (e.g. "git tag" and "git branch" are primarily to create these things, just like "git commit" is to create a commit), it is more natural to give the primary mode the main interface so that you do not have to say "git tag create v1.0"; hence operating mode option makes sense than subcommand.

On the other hand, when a command does not have a clear primary mode (e.g. if you save a stash you must be able to use (i.e. apply or pop) the saved one and both are equally important feature), but its primary purpose is to dispatch various different operation, it makes more sense to name them as subcommands. You _could_ make all of them into operating mode options, but that only requires more typing, i.e. "git stash --save"/"git stash --pop", without adding much value to the command. In addition, it invites unnecessary confusion "what is the default mode of operation, and is it really that important to be the default?", because not requiring an explicit "subcommand" but merely allowing "operation mode option" implies that you can say "git cmd" without anything, i.e. there must be some default.

For "stash", "save" has been the default merely by historical accident, but that has been rectified (it now requires you do not have any message for the quick stash "git satsh<ENTER>" to work). There really isn't any "default" operating mode to the command, and the command is a dispatcher to its subcommands.