Re: Git's inconsistent command line options

[Jacob Keller <jacob.keller@gmail.com>]

On Tue, Aug 25, 2015 at 3:06 PM, Stefan Beller <sbeller@google.com> wrote:
> On Tue, Aug 25, 2015 at 2:49 PM, Jacob Keller <jacob.keller@gmail.com> wrote:
>> On Tue, Aug 25, 2015 at 8:13 AM, Junio C Hamano <gitster@pobox.com> wrote:
>>> On Tue, Aug 25, 2015 at 1:01 AM, Graeme Geldenhuys <graemeg@gmail.com> wrote:
>>>>
>>>> Even though I have worked with Git since 2009, I still have to
>>>> reference the help to remind me of what parameter to use in certain
>>>> situation simply because similar tasks differ so much.
>>>>
>>>> Maybe we could address this in the next major version of Git? Has
>>>> anybody else thought about this or started work on this? Or was this
>>>> discussed before and declined (link?).
>>>
>>> http://article.gmane.org/gmane.comp.version-control.git/231478 comes to mind,
>>> which has been linked from this entry:
>>>
>>> Discuss and decide if we want to choose between the "mode word" UI
>>> (e.g. "git submodule add") and the "mode option" UI (e.g. "git tag --delete")
>>> and standardise on one; if it turns out to be a good idea, devise the migration
>>> plan to break the backward-compatibility.
>>>
>>> in http://git-blame.blogspot.com/p/leftover-bits.html
>>
>> I would vote for command words, as this is clean and simple.
>
> me too after rereading the arguments in that thread.
>
>> The
>> downside is in converting all the old options based commands, git-tag,
>> and similar. These commands cannot easily convert because "valid"
>> sequences would become invalid with no easy way to deprecate for
>> example in the linked gmane above, "git tag delete master" can't be a
>> call to delete master as it is currently a call to create a tag
>> "delete" at the commit marked by master.
>
> git-tag being a porcelain command (i.e. we do not give a promise to keep
> it set to stone) can be changed with a deprecation announcement period.
> Say starting with Git 2.6 we would put out warnings for upcoming commands:
>
>  $ 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 ?
>
> $ git tag create delete
>
> And after a while (maybe 3-5 years, once this version is picked up by
> debian stable as well as red hat stable)
> we can change it, so with Git 3.4(?)
>
>  $ git tag --delete master
>  # --delete is deprecated since 3.4, use `git tag delete` instead
>  $ echo $?
>  # 128
>
>  $ git tag delete master
>  # --delete is deprecated since 2.6, use `git tag delete` instead
>  $ echo $?
>  # 0 # actually works!
>


This seems like a possible strategy for converging on command words.
So basically, we force all uses of the command words to just fail and
then once that's picked up we can migrate to the command words.

Regards,
Jake