For git branch -c one could say that the "branch" command should not do checkout-business.

The issue is that "-b" (mnemonic for "branch") in no way suggests that it creates a new branch. Since checkout does so many different things, it would be reasonable to guess that -b limits the command to perform the "branch" action (i.e. switch to a branch). Git-switch doesn't have this issue.

Either switch/checkout will create or branch will switch.

I don’t see why choosing one for double duty is inherently worse than the other.

But I do consider your proposal of `git branch —create` as a poor command for create and switch branch.

The `git checkout -b` and `git switch -c` docs specifically note that they're shortcuts for going a git branch then a git checkout/switch.

The git switch subcommand's description is "Switch branches", so clearly it, too, is intended to handle a subset of the cases where you want to do something with a branch. Switching to a branch that doesn't already exist is a special case of git-switch's main purpose, and you have to be explicit about it. Further, when you create a new branch, you just about always want to switch to it (because while you can do some things with a branch that's not checked out, most commands are designed to work on the currently-checked-out branch), so what's the point in forcibly separating the commands?

> But a shortcut for "git branch -c" would be better if you want to keep the "create and switch" shortcut IMO.

Strongly disagree. In Git, creating a branch is a much smaller action than changing the state of your checkout. It makes much more sense to have the branch creation as the side effect than the other way around.

And all of git's branches are pretty light and flexible, at least compared against the branches of the previous generations of version control systems..

But yeah. That's definitely not what they were intending.