changing the experimental 'git switch' (was: [Summit topic] Improving Git UX)

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

On Thu, Oct 21 2021, Johannes Schindelin wrote:

>  7.  Ævar: On switch/restore in particular, there was a recent discussion.
>
>      1. Ultimately came down to inconsistency with other commands in the same
>         area
>
>      2. I gave some suggestions

Those suggestions are at:
https://lore.kernel.org/git/877dkdwgfe.fsf@evledraar.gmail.com/ copying
the most relevant part from that:

In summary, I think it should be changed to act like this:
    
    |---------------------------+------------------------+---------------------------|
    | What                      | Now                    | New                       |
    |---------------------------+------------------------+---------------------------|
    | Switch                    | git switch existing    | git switch existing       |
    | Error                     | git switch nonexisting | <no change (errors)>      |
    | Switch with --merge       | git switch -m branch   | git switch --merge branch |
    | Create                    | git switch -c new      | git switch -n new         |
    | Create from existing      | N/A                    | git switch -c new [<old>] |
    | Move & switch to existing | N/A                    | git switch -m new [<old>] |
    |---------------------------+------------------------+---------------------------|

>      3. Some patches started, there was some trepidation about making changes,
>         though

I was thinking of this patch, i.e. it implements the "-n" option for
"git
switch": https://lore.kernel.org/git/20210709174310.94209-1-felipe.contreras@gmail.com/

We could then add the same to "git branch", i.e. "git branch foo" could
also be invoked as "git branch -n foo".

We'd then need to have a hard change in the semantics of the
(experimental) "git switch" commant to make "-c" mean "copy" (like in
"git branch").

We'd then reach an end-state where these two commands would behave in
the same way for these common options, with the difference being that
"branch".

Whatever anyone thinks of my specific suggestions there I think that in
general we should be trying to aim more towards that in git's UI, even
to the point of slowly phasing in deprecations for non-experimental
commands. E.g. the "-n" option to "git fetch" comes to mind, which isn't
a synonym for "--dry-run", as in most other places.

I realize that doing that is hard, e.g. Josh Steadmon has a patch
on-list now to add a configurable "inherit" mode to "git branch[1].

I noted in a similar vein as the table above that it would leave us with
another inconsistency between "branch" and "checkout"/"switch" in [2].

Does that mean we shouldn't take that patch and others like it until
such UX inconsistencies are addressed?

I really don't know, but I do think that the most viable path to a
better UX for git is to consider its UX more holistically.

To the extent that our UX is a mess I think it's mainly because we've
ended up with an accumulation of behavior that made sense in isolation
at the time, but which when combined presents bad or inconsistent UX to
the user.

1. https://lore.kernel.org/git/9628d145881cb875f8e284967e10f587b9f686f9.1631126999.git.steadmon@google.com/
2. https://lore.kernel.org/git/87a6j6tbsv.fsf@gmgdl.gmail.com/