Stefan Beller <stefanbeller@xxxxxxxxxxxxxx> writes:
> On 07/31/13 00:28, Junio C Hamano wrote:
>>
>> we could just do
>>
>> #define OPT_CMDMODE(s, l, v, h) \
>> { OPTION_CMDMODE, (s), (l), (v), NULL, \
>> (h), PARSE_OPT_NOARG|PARSE_OPT_NONEG, NULL, (s) }
>>
>
> I agree that's a better proposal than mine.
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).
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html