Re: git switch/restore, still experimental?

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: May 6, 2021, 10:02 UTC
Message-ID: <87pmy4uqhz.fsf@evledraar.gmail.com>
In-Reply-To: <xmqq35v01ua3.fsf@gitster.g>

On Thu, May 06 2021, Junio C Hamano wrote:

Show 17 quoted lines

> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
>
>> I mean, I see why. You don't want a typo of "master" as "maaster" to
>> create a new "maaster" branch, so really that's out. But it really
>> should be:
>>
>>     # -n or -N for --new / --new --force (the latter just in case of a
>>     # race, and just for consistency)
>>     git switch -n doesnotexist
>
> I do not see why --new is better than --create; we did choose not to
> reuse --branch from "checkout" and I remember that was a deliberate
> decision (i.e. once split into "switch" and "restore", "switch"
> becomes only about branches, so unlike in the context of "checkout",
> in the context of "switch", the word "branch" adds a lot less value,
> and certainly does not signal we are creating a branch and switching
> to it).

I don't think --new is better than --create when considered in isolation. I happen to think --create is better.

What I'm arguing is that we should be aiming for some consistency in the command-set. In this case the relatively small change of s/--create/--new/ server so make the rest consistent. I.e. the branch and switch commands can mirror each other in the ways that matter for these common operations of create/copy/move.

> It would have been a stronger argument to favor --new if we had "git
> branch --new <branchname>", but that is not the case.

The argument is that switch's experimental design squats on 2x other options, so changing -c to -n so we can make -c and -m do the same thing is better.