From: Junio C Hamano <gitster@pobox.com>
To: Nadav Goldstein <nadav.goldstein@blazepod.co>
Cc: git@vger.kernel.org, gitgitgadget@gmail.com, nadav.goldstein96@gmail.com
Subject: Re: [PATCH] stash: added safety flag for stash clear subcommand
Date: Wed, 18 May 2022 13:51:31 -0700 [thread overview]
Message-ID: <xmqqy1yytvho.fsf@gitster.g> (raw)
In-Reply-To: <CAApwGmCsQNK42=5x1OxdovgVxdzj2Vs5H1FaUJhAGCXvmA5pzw@mail.gmail.com> (Nadav Goldstein's message of "Wed, 18 May 2022 21:53:36 +0300")
Nadav Goldstein <nadav.goldstein@blazepod.co> writes:
> If we make "git stash clear" to by default not clear the stash and
> just present the stashes to be dropped (and require -f to force
> clearing the stash), wouldn't we essentially make a duplicate of "git
> stash list"?
Correct, but that is not what I would imagine to be a parallel to
"git clean [-f|-n]" with clean.requireForce. If you haven't played
with "git clean" with various settings of that variable, you should.
Its behaviour illustrates pretty well what I meant in the message
that prompted your response, to which I am responding to. I would
imagine that "git stash clear [-f|-n]" with stashClear.requireForce
to be more like:
* stashClear.requireForce that is not set is treated as if it is
set to true;
* "git stash clear" without -f or -n will die with a single line of
message, telling the user to give either -f or -n, unless the
configuration is set explicitly to 'false'.
It will be more like "confirmation" to those who run "git stash
clear", and then if they are certain, run "git stash clear -f".
Of course, "interactive" can be added like "git clean -i".
Just like "-i" defeats the refusal by "clear.requireForce" when
running "git clean", "git stash clear -i" would go interactive and
should be usable regardless of what value stashClear.requireForce
has.
> Regarding making it opt out instead of opt in, I am afraid there are
> tools that use git stash clean automatically, and making the
> confirmation opt-out (by default confirm) we can potentially break
> them, don't you think it would be more gentle to the git community to
> make it opt in?
It is usually a good idea to introduce such a disruptive feature
gradually by first making it opt-in, with a warning message to tell
users that the default will change in the future. For this feature,
it may go like this:
1. Phase one.
* "git stash clear" learns "-f|--force" and "-n|--dry-run"
options.
* A configuration variable stashClear.requireForce is introduced.
"git stash clear" starts paying attention to it. When it is
- set to true, "git stash clear" without "-f" or "-n" errors
out.
- set to false, "git stash clear" works just like today. No
extra messages, no extra errors.
- unset, "git stash clear" gives a warning message to tell the
users two things:
- The stashClear.requireForce configuration variable exists
and when it is set to true, you need to pass "-f" to make
"git stash clear" actually clear. When it is set to false,
the stash is cleared just like before. When it is unset,
you will see this warning message, but the command clears
the stash.
- The default value of stashClear.requireForce will become
true in a future version of Git, and users are encouraged to
set their preference early by setting the configuration
variable now.
but otherwise it goes ahead and clears the stash.
* Release notes talks about upcoming default flip for the variable.
2. Phase two (probably several releases after Phase one).
* The behaviour of "git stash clear" is changed so that when
stashClear.requireForce is
- set to true of false, it behaves identically as phase one.
- unset, "git stash clear" gives a warning message to tell the
users about the stashClear.requireForce variable just like in
phase one (the description needs to be adjusted to say that
the default value is now 'true'), and behaves as if the
variable is set to 'true'.
3. Phase three (probably several releases after Phase two).
* Long after users have adjusted to the new "safer by default"
behaviour, we shorten the error message given to those who do not
have the variable configured, similar to the message "git clean"
gives to those without clear.requireForce.
next prev parent reply other threads:[~2022-05-18 20:57 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-18 18:53 [PATCH] stash: added safety flag for stash clear subcommand Nadav Goldstein
2022-05-18 20:51 ` Junio C Hamano [this message]
-- strict thread matches above, loose matches on Subject: below --
2022-05-18 21:05 Nadav Goldstein
2022-05-15 21:18 Nadav Goldstein via GitGitGadget
2022-05-16 3:17 ` 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=xmqqy1yytvho.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=nadav.goldstein96@gmail.com \
--cc=nadav.goldstein@blazepod.co \
/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).