Re: Git's inconsistent command line options

[Junio C Hamano <gitster@pobox.com>]

Stefan Beller <sbeller@google.com> writes:

>  $ git tag --delete master
>  $ echo $?
>  # 0 # actually works as of today!
>
>  $ git tag delete master
>  #  Due to the planned switch to command words, this doesn't work.
>  #  For details see road map at  `man git commandwords-roadmaps`
>  $ echo $?
>  # 128 maybe ?

This is way too aggressive behaviour and is unacceptable as the
first step.  The first step of a transition that breaks backward
compatibility should warn loudly about a command line that would
behave differently in the endgame version (either the command line
that will not do anything or do a totally different thing), but
still perform the operation asked for the current version.

    e.g. "git tag delete master" would create a tag named 'delete'
    out of 'master', but tell the user that this will instead delete
    'master' in future versions of Git.  "git tag create master"
    would create a tag named 'create' out of 'master', but tell the
    user that this will instead create 'master' out of HEAD in
    future versions of Git.

    e.g. "git tag -d foo" would delete a tag named 'foo', but tell
    the user that this will have to be spelled 'git tag delete foo'
    in the future versions of Git.

One thing that I am not enthused about the transition plan is that
"git tag delete master" will *never* be an invalid operation during
the transition.  When making an operation that used to mean one
thing to mean something else, a good transition plan should be to

 * First warn but do the old thing, and tell users a new way to do
   that in the new world order.  At the same time, find the new way
   that used to be an invalid operation in the old world order, and
   implement it.

 * Then stop supporting the old thing and support only the new
   thing.

Then during the transition period, while transitioning to the new
way, people can gradually start using the new way with the new
system, and when they occasionally have to interact with an old
system, the new way will _error out_, because we make sure we find
the new way that "used to be an invalid operation" when planning the
whole transition plan, without causing any harm.  And once people
retrain their finger after 2-3 years, nobody will be hurt if we
dropped the old way.

I do not see a good way to do such a safe transition with command
words approach, *unless* we are going to introduce new commands,
i.e. "git list-tag", "git create-tag", etc.

So don't hold your breath.  What you two are discussing is way too
uncooked for 2.6 timeframe.