(Going through old mail today, sorry for the late reply)
On 08/01/2013 12:10 AM, Junio C Hamano wrote:> Stefan Beller
<stefanbel...@googlemail.com> 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).
>
Why not encourage the use of a standardized '--action' option instead?
This can work with lesser compatibility headaches for both the commands
taking mode options and the commands taking mode words:
"git submodule init" becomes "git submodule --action=init"
"git tag --delete TAG" becomes "git tag --action=delete TAGNAME"
Commands that have a "primary operation mode" can keep the use
of --action optional, while commands that have no such sensible
primary mode can make it mandatory (again, this gives more compatibility
with the existing syntax). And the old syntax
can be supported in parallel to the new one for a potentially
indefinite time; albeit, if I were to propose a timetable, I'd
got for:
- Git 2.0: the new syntax is introduced
- Git 2.x: any use the old syntax starts to trigger warnings
(which can be silenced with a config option)
- Git 3.0: any use the old syntax starts to trigger fatal
errors (which can be turned into mandatory warnings with
a config option)
- Git 4.0: any use the old syntax starts to trigger
mandatory fatal errors.
- Git 4.x: Remove any handling of the old syntax.
Just my 2 cents,
Stefano
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
