Re: Git's inconsistent command line options

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 25, 2015, 23:43 UTC
Message-ID: <xmqqa8tfvsr9.fsf@gitster.dls.corp.google.com>
In-Reply-To: <CAGZ79kZ6KK0qVtzrxmmsBQqmz-dgamC4f6W0zVTQLcuYi==0fw@mail.gmail.com>

Stefan Beller <sbeller@google.com> writes:

Show 9 quoted lines

>  $ 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.