From: Erik Huizinga <huizinga.erik@gmail.com>
To: git@vger.kernel.org
Subject: Why are experimental commands git restore and git switch suggested in CLI output?
Date: Sat, 2 May 2020 09:18:26 +0200 [thread overview]
Message-ID: <CADA507xceVtpNkK5hyUrnXM0rPBj=sgpR0eM7b+yybiWT6Cg3w@mail.gmail.com> (raw)
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
next reply other threads:[~2020-05-02 7:18 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-02 7:18 Erik Huizinga [this message]
2020-05-02 16:44 ` Why are experimental commands git restore and git switch suggested in CLI output? Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CADA507xceVtpNkK5hyUrnXM0rPBj=sgpR0eM7b+yybiWT6Cg3w@mail.gmail.com' \
--to=huizinga.erik@gmail.com \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).