Re: [PATCH] switch: add --ensure option

[Junio C Hamano <gitster@pobox.com>]

"Lei Zhu via GitGitGadget" <gitgitgadget@gmail.com> writes:

> Users who often switch between topic branches may not know whether the
> local branch already exists. Without this option, they need to check
> for the branch first and then choose between `git switch <branch>` and
> `git switch -c <branch>`. The new option folds that workflow into a
> single command.

Quite honestly, I am not sure if the use case should be supported
with a new option, or we should actively discourage it by rejecting
any patch that takes us in this direction, as the actions the user
would take after seeing the result of "git checkout -b" or "git
switch -c" are quite different among (just off the top of my head):

 (1) Ah we already had the branch created exactly to work on this;
     instead of forking a new effort, switch to the existing branch
     and build on the effort we made previously, as it forks from an
     acceptable base, which might have been different from where we
     wanted to start at when we said "git switch -c <branch> <base>".

 (2) Ah we already had the branch created exactly to work on this.
     Unfortunately, it was forked from way too new base before we
     realized that this is also an important bugfix that needs to be
     mergeable to the maintenance track.  Let's create a new branch
     that is a copy of the existing one with "-maint" in its name,
     rebase it on the maintenance track, and work there.

 (3) Ah we already had a branch that happened to have the same name,
     but created for totally different reasons.  We do want to fork
     a new branch but need to give it a different name.

 (4) There wasn't a branch with the given name, so we created a new
     branch at the right starting point we just picked when we ran
     "git checkout -b"/"git switch -c".  Let's start working on the
     topic.

You cover *only* case (4) perfectly.  When your "-c <branch>" picks
an existing branch, the user still needs to figure out which among
situations (1)-(3) (of course, there may be others) they are in, and
act accordingly.  "git checkout -b" and "git switch -c" that fails,
reminding that there is an existing branch with the same name, gives
users a stronger form of reminder than switching blindly to the
existing branch, which may (in case (1)) or may not (in cases (2)
and (3)) be where the user wants to be when taking the next action.

Having said that.

 * The option name "-e" would make all users expect that this has
   something to do with "--editor".  Start with a longer name,
   perhaps "--create-if-missing" or something, and then see if
   others can come up with a better short-hand.  Obviously whoever
   chooses "-e" is not equipped well to do so (yet), and the
   reviewer who pointed out "-e" is not a good idea without being
   able to offer a better alternative is not, either ;-).

 * Adding a new flag only to "switch" without "checkout" will
   unnecessary confuse users.  This is because, even though
   "switch/restore" started as an experiment to _supersede_
   "checkout", they were not successful, not in the sense that
   "switch/restore" were harder to use than the original, but in the
   sense that the userbase and teaching materials are already used
   to the original and removing it is practically infeasible.