On Tue, Sep 14, 2021 at 04:35:42PM -0400, Derrick Stolee wrote: > > We should definitely work to find a better way to describe our > vision for how _the ideas in Scalar_ can be adopted into Git proper. > .. > > But the way I see Scalar being fully incorporated into Git is not as > a "git scalar <foo>" command or even having "scalar" be included by > default. I agree 1000%. It may be convenient for existing scalar users to have a way they can stick with the CLI that they are used to, but before we add this functionality to git proper, let's please make sure git users get a CLI which makes sense and not dictated by history. We already have enough people who complain that the git interface design is hard to understand but which can't be changed because we bias our UI design in favor of existing users as opposed new users. Given that I'm an existing user, I'm actually not complaining, but I do recognize the validity of the complaints that for example, git reset does three different, mostly unrelated things. Given that the existing scalar users are used to "scalar <foo>" and not "git scalar <foo">, I'd gently suggest that it's better that there be an existing compatibility program which translates "scalar <foo>" to whatever git command(s) makes sense, as opposed to optimizing for the simplicity of said program so that all forms of "scalar <foo>" should get translated to "git scalar <foo>". So for example, if we are inside a mono repro, it would seem to me that "git commit" should automatically do the right thing, as opposed to imposing cognitive load on the user to know when they are supposed to type "git commit ..." versus "git scalar commit ..." versus "scalar commit". Please, let's design the UI for scalar integration into git with deep sympathy for the users, and *not* the convenience of the compatibility script for the existing scalar CLI users. - Ted
