Re: [PATCH] tag: Use OPT_BOOL instead of OPT_BOOLEAN to allow one action multiple times

Stefan Beller <stefanbeller@googlemail.com> writes:

By the way, I haven't convinced myself that it is a good idea in general to encourage more use of command mode options, so I am a bit reluctant to add this before knowing which direction in the longer term we are going.

 - Some large-ish Git subcommands, like "git submodule", use the
   mode word (e.g. "git submodule status") to specify the operation
   mode (youe could consider "status" a subsubcommand that
   "submodule" subcommand takes).  These commands typically began
   their life from day one with the mode words.

 - On the other hand, many Git subcommands, like "git tag", have
   "the primary operation mode" (e.g. "create a new one" is the
   primary operation mode for "git tag"), and use command mode
   options to specify other operation modes (e.g. "--delete").
   These commands started as single purpose commands (i.e. to
   perform their "primary operation") but have organically grown
   over time and acquired command mode options to invoke their
   secondary operations.

As an end user, you need to learn which style each command takes, which is an unnecessary burden at the UI level. In the longer term, we may want to consider picking a single style, and migrating everybody to it. If I have to vote today, I would say we should teach "git submodule" to also take command mode options (e.g. "git submodule --status" will be understood the same way as "git submodule status"), make them issue warnings when mode words are used and encourage users to use command mode options instead, and optionally remove the support of mode words at a large version bump like 3.0.

One clear advantage mode words have over command mode options is that there is no room for end user confusion. The first word after "git subcmd" is the mode word, and you will not even dream of asking "what would 'git submodule add del foo' do?" as it is nonsensical. The command mode options, on the other hand, gives too much useless flexibility to ask for nonsense, e.g. "git tag --delete --verify", "git tag --no-delete --delete", etc., and extra code needs to detect and reject combinations. But commands that took mode options cannot be easily migrated to take mode words without hurting existing users and scripts (e.g. "git tag delete master" can never be a request to delete the tag 'master', as it is a request to create a tag whose name is 'delete' that points at the same object as 'master' points at).