Re: Git's inconsistent command line options

From: Michael J Gruber <git@drmicha.warpmail.net>
Date: Sep 9, 2015, 09:42 UTC
Message-ID: <55EFFF11.8000500@drmicha.warpmail.net>
In-Reply-To: <20150901092834.GA10706@gmail.com>

David Aguilar venit, vidit, dixit 01.09.2015 11:28:

Show 31 quoted lines

> On Mon, Aug 31, 2015 at 10:25:58AM -0400, Barry Warsaw wrote:
>> On Aug 31, 2015, at 05:10 PM, Duy Nguyen wrote:
>>
>>> I'm probably shot down for this. But could we go with a clean plate
>>> and create a new command prefix (something like git-next, git2, or
>>> gt...)? We could then redesign the entire UI without worrying about
>>> backward compatibility. At some point we can start to deprecate "git"
>>> and encourage to use the new command prefix only. Of course somebody
>>> has to go over all the commands and options to propose some consistent
>>> UI, then more discussions and coding so it could likely follow the
>>> path of pack v4..
>>
>> `git` itself could also be a thin wrapper which consulted a configuration
>> variable to see which version of the ui to expose.
>>
>> "All problems in computer science can be solved by another level of
>> indirection"
> 
> Except for poor performance, simplicity, and bad ideas.
> 
> The Git project does not break backwards compatibility.
> Let's let Python3 serve as a good lesson on why not to do that! ;-p
> 
> While a script writer could write, "git -c core.cliversion=1 ...",
> no one does that, no one wants to do that, and it just seems
> like a bad idea that's best left unexplored.
> 
> The only idea in this thread that's user-friendly would be a new
> Git that still supported the entirety of the existing,
> perfectly-good CLI interface and *also* accepted some new
> "consistent" user interface.

Give it a break. If Git had a perfectly-good CLI interface we didn't have any complaints. But we have many well-founded complaints about inconsistencies, such as short-options (-n), subsubcommands etc.

> Otherwise, this entire thread seems like a big non-issue.
> The existing CLI hasn't hurt adoption, and tossing a config
> option at it only makes it worse.  The best config is no config.

I certainly agree with you on that. Unfortunately, we've seen quite an increase of config options whose sole purpose is changing default options for some commands.

Show 8 quoted lines

> There really are ony a few corner cases that would need to be
> tweaked to support --named-subcommands style, and after that is
> done, is Git really that much easier to use?
> 
> Maybe a little bit, but not enough that warrants breaking
> existing scripts IMO.
> ---
> David

Well, it may actually hurt to reach some substantial improvements. It may actually be worth it if it ends constant suffering from how it is now. Those are the points that we have to weigh carefully. Simply resisting change won't take us anywhere.

Michael