On 20/02/2024 19:04, Junio C Hamano wrote:
[References]
*1* https://lore.kernel.org/git/211021.86wnm6l1ip.gmgdl@xxxxxxxxxxxxxxxxxxx/
*2* https://lore.kernel.org/git/xmqqzg6eocmi.fsf@gitster.g/
From 2
I think the "switch" was written exactly for such a transition so that folks who
wanted a different behaviour do not have to break existing users of "checkout".
Yet then the table in link 1 suggests to re-use -c and -m in the old
style, the way the currently are used in "git branch"
"Introducing a new behaviour" is exactly not having to copy old meanings
of options...
As I wrote
The flaw here is in "git branch" which by default list branches, but if give a name (and no option to specify an action) "git branch foo" will change its action to "create".
If "git branche" actually had needed an option to change its action to
create, what would it have been? --create or -c ?
And -n (as suggested in the table) is strongly associated with dry-run.
(not only in git)
If I look at the suggestion to replace -m by --merge, just so that -m
can be "move", then I seriously ask, what happens more often:
- Someone switching to a branch while having modifications in their
worktree (needing to merge)
- Someone creating a new branch, wanting to copy reflog/options
Given not only that switching to a new branch happens more often than
creating one (and thereby makes it alt least plausible, that the -m as
"merge" is required more often)..., but also that "git switch" is more
about switching than creating branches..., I believe that -m as "merge"
is entirely the better choice.
For the "git branch" features, if "git switch" should support them, they
could easily be made available as
--cc create and copy
--mv move
They - by all likelihood - are used less often, and should be the long
options. And a 2 letter long option is still easy to use.
