builtin: remove experimental label git-switch and git-restore

builtin: unmark git-switch and git-restore as experimental

Greetings,

In 4e43b7ff (Declare both git-switch and git-restore experimental, 2019-04-25), the newly introduced git-switch(1) and git-restore(1) commands were marked as experimental. This was done to provide time to make breaking changes to the interface. It has now been over six years since these commands were implemented and, over this time, there has not been much change that would warrant these commands being labeled as experimental.

There was a patch submitted 1 about a year ago also with the intent to remove the experimental marker for these commands, but fizzled out seemingly due to uncertainty around whether past discussions around git-switch(1) had been resolved. Digging through some of these conversations 2, a point of concern for git-switch(1) was around some of the chosen short flags for git-switch(1), namely the -c flag for creating a branch and the -m flag for merging unstaged changes into the target branch.

At this point, it seems rather difficult to justify changing -c/--create to something different as it has been that way for a long time and is used frequently. Also I'm not entirely convinced switching to something like -n/--new is much better as it would run into a similar issue of taking the short flag commonly used for the --dry-run option. As for the -m/--merge flag, I don't think there is much harm in dropping the short flag for what I presume to be a relatively uncommon option. Outside of these explicitly brought up concerns though, I have not found anything that would require a breaking change to git-switch(1).

By removing the experimental marker, we help clarify the stability and maturity of these commands. It will also make it easier for users to adopt and recommend, as the experimental label has been a point of hesitation for some. For new users, git-switch(1) and git-restore(1) do help avoid some confusion that comes with the one-command-do-all git-checkout(1) so helping to further promote their use should be beneficial.

Thanks, -Justin

Related: #496 (closed)