Why are experimental commands git restore and git switch suggested in CLI output?

Why are experimental commands git restore and git switch suggested in CLI output?

[Erik Huizinga]

Hello!

Lately I've noticed that when I checkout a branch or show the working
tree status, then the CLI output suggests that I can perform certain
actions with new commands (since v2.23 if I'm not mistaken) restore
and switch. This is very nice, because I like to see these UI
enhancements. However, reading the help pages for these commands shows
'THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE.' This is
somewhat discouraging use, because I don't want to learn to use these
commands if their behavior may change. This could mean that what I
learn about these command may not be usable on future git versions.

My questions about this are:

1. What is the git maintainers' policy regarding experimental features
like restore and switch? Apparently, they are there to be discovered
in plain sight, while experimental. Using experimental features may
not be what the user wants.
2. What exactly may change about these commands' behavior? Are the
superficially suggested actions stable? Are they stable within a patch
or minor git version only? Are existing use cases stable, or can they
be removed or incompatibly change under this experimental policy?

In other words: how can I, an individual end user, know what I can
safely learn about these commands, and what can not?

Thank you in advance for your time and answers. :)
Erik Huizinga

Re: Why are experimental commands git restore and git switch suggested in CLI output?

[Junio C Hamano]

Erik Huizinga <huizinga.erik@gmail.com> writes:

> In other words: how can I, an individual end user, know what I can
> safely learn about these commands, and what can not?

The restore/switch commands are thought to be the future, and for a
better future, we still want to polish them further, which means
they may gain new features, their existing behaviour may change, or
some features that are found to be bad for users may be dropped.

And we will know what new features are desirable, which parts of
their existing behaviour should be improved in what way, and which
parts of their existing features cause confusion to users and need
to be dropped, only by listening to those who actually use them in
their daily life.  That is what an experiment is.  By definition,
we won't know what will going to change.

Users who want to help improve future Git are encouraged to use
these experimental commands and complain (especially when they find
that these commands do not work for them in their workflow better
than "git checkout", which these commands are meant to replace).
Their voices will be heard and the commands may gain what they want
and lose what they do not want.

Users who do not care about participating in polishing these two
commands for a better Git in the future can stick to what they
already know, "git checkout".  But eventually these users would have
to learn "switch/restore" and their then-current set of features, as
(hopefully) they would be much better than "git checkout" by then.

Thanks.