Re: git switch/restore, still experimental?

From: Felipe Contreras <felipe.contreras@gmail.com>
Date: May 6, 2021, 21:55 UTC
Message-ID: <609465b55e183_577f20852@natae.notmuch>
In-Reply-To: <87h7jfvq09.fsf@evledraar.gmail.com>

Ævar Arnfjörð Bjarmason wrote:

> On Thu, May 06 2021, Felipe Contreras wrote:

Show 10 quoted lines

> > If you use natural language:
> >
> >   1. Git, switch to a new branch
> >
> >   2. Git, switch, create, branch
> >
> > One of these simply flows, the other is complete gibberish. I think
> > anyone familiar with English can identify which is which.
> 
> Well, there's "Git, create a new branch and switch to it"

Which command is that?

  git create branch --checkout?

I'm following the order of the words from left to right.

> Also, there's the verb "make" in common use in git's command set
> e.g. git-mktag, git-mktree, as well as mkdir(1), mkfifo(1) etc.

Sure, although I wouldn't consider them main commands. I for one never use them.

Show 5 quoted lines

> In any case, unless we're talking about rewamping git's entire command
> set (e.g. having a git-newtree or whatever) I'd like to think that it's
> more productive to focus on making the commands/switches we have
> internally consistent when possible, which is what I'm advocating in the
> E-Mail that started this sub-thread.

But we are talking about a new command, it is precisely at this point we need to think about what could have been if mistakes of the past had not happened.

We should not repeat past mistakes without a very good reason.

I don't think we should seek consistency for consistency's sake. Sure, consistency is good, but it's only one of many considerations.

In this case however we have a rare occasion in which both consistency and natural language meet, we should not squander it.

In fact, to be even more consistent we could add a -n option to git branch, which would be reduntant but more explicit, like --list.

Cheers.

-- 
Felipe Contreras