Re: Git's inconsistent command line options

[David Aguilar <davvid@gmail.com>]

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.

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.

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