Re: Git's inconsistent command line options

From: Jacob Keller <jacob.keller@gmail.com>
Date: Aug 26, 2015, 23:02 UTC
Message-ID: <CA+P7+xqYMHfMuBKtGK_p8mwbLjEJWN80i1oDyCdJ_0iVZPmhaQ@mail.gmail.com>
In-Reply-To: <500FC504AB174A98B31CD8BEFCDDCFAC@PhilipOakley>

On Wed, Aug 26, 2015 at 3:52 PM, Philip Oakley <philipoakley@iee.org> wrote:

Show 25 quoted lines

> From: "Jacob Keller" <jacob.keller@gmail.com>
>>
>> On Wed, Aug 26, 2015 at 10:56 AM, Junio C Hamano <gitster@pobox.com>
>> wrote:
>>>
>>> But notice that I said "if you really want to".  I personally think
>>> it is a road to madness.
>>
>>
>> Agreed. I don't believe in command line API here. I think we'd need a
>> better solution.
>>
>> My gut says: Live with the warts on old commands and try to make
>> people use command words for new commands.
>> --
>
> Agreed. However Graeme's original question also said "I can supply a more
> extensive list if needed", and "I still have to reference the help to remind
> me of what parameter to use in certain situation", which suggests that one
> option is to capture that list within some part of the documentation,
> especially if Graeme already has an easy to read layout.
>
> If it could be part of the documenation, where should it go - gitcli or
> perhaps it's own guide (`git help -g` and friends)?
>

I hope to spend some time investigating this in the near future. Personally I feel that command names make more sense than options since they are essentially non-options, and it helps separate logically related but non-equivalent operations more easily.

The confusion that results from git-checkout, and git-branch has caught more than a few new people at $dayjob.

Regards, Jake