> It clearly should be the "git branch" subcommand's responsibility, because "You want to do something with a branch".
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.
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.