Re: Git's inconsistent command line options

[Michael J Gruber <git@drmicha.warpmail.net>]

Stefan Beller venit, vidit, dixit 01.09.2015 19:56:
> On Tue, Sep 1, 2015 at 10:50 AM, Barry Warsaw <barry@python.org> wrote:
>> On Sep 01, 2015, at 09:42 AM, Junio C Hamano wrote:
>>
>>> That way, you are forcing all the existing scripts to be updated to
>>> say "git -c ..." for _all_ invocations of Git they have, aren't you?
>>
>> No, why?  If the default value enables the current ui, then no scripts need
>> changing.  Users can enable the new ui for their own benefit at their own
>> pace.  If you eventually want to make the new ui the default, provide a
>> sufficient transition period.
>>
>> Cheers,
>> -Barry
> 
> So say I am a user who wants to take the new command set. And as I am lazy to
> type it all the time I just do:
> 
>   $ git config --global command-version 2
> 
> Now I have all the new fancy stuff when I type it directly into the terminal.
> But when I run one of the old scripts my coworker gave me (which is used to
> the old notion), it must adhere to the old command world. How do you now figure
> out if this is interactive or script?

You can't. We have that exact same problem already with the recent
option-overriding config bloat. It needs to be solved sooner or later
anyways, by introducing some sort of "mode" (interactive vs. scripting),
since while in principle we have a separation between porcelain and
plumbing commands, we don't have, say, a plumbing version of "git tag"
and take that as an excuse^Wreason for any change to the porcelain
command "git tag". (You can freely interchange the roles here.)

Really, that porcelain-plumbing separation that's often mentioned is
more wishful thinking than actual reality, at least no complete reality,
or else we wouldn't even have any backward compatibility problem to
solve here.

So, UI rework or not, we should think about making that promise real: a
clear separation between a stable scripting interface and an evolving
user interface. Two possible ways are:

- separate commands, such as git-log vs. git-rev-list
- separate modes for the same commands

We use both of them ("interactive" detection for some default settings),
but partially only.

Michael