On Thu, May 06 2021, Ævar Arnfjörð Bjarmason wrote:
On Thu, May 06 2021, Junio C Hamano wrote:
*Poke*
quoted
Ævar Arnfjörð Bjarmason [off-list ref] writes:
quoted
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.
quoted
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.
Whatever the merit of the argument I'm putting forward here, it would be
useful to get some idea of whether you'd be categorically opposed to
changing the interface of switch/restore in breaking ways even though
they've been marked as "THIS COMMAND IS EXPERIMENTAL".
Of course any series to implement what I suggested in
[ref] would need to stand on its own
merits.
I'm not planning on working on that since I expect the response will be
at best "neat, but that ship has sailed", but if that's not the case...