threads / discuss / 53371

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

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

## tl;dr

2 messages between May 2, 2020 and May 2, 2020.

replies: 1people: 2as markdown or json

Erik Huizinga· May 2, 2020, 07:18 UTC · lore
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

Junio C Hamano· May 2, 2020, 16:44 UTC · re: Erik Huizinga · lore

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

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.

← back to recent threads