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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html