git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Nadav Goldstein <nadav.goldstein96@gmail.com>
To: Junio C Hamano <gitster@pobox.com>,
	Nadav Goldstein via GitGitGadget <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org, Derrick Stolee <derrickstolee@github.com>
Subject: Re: [PATCH v3] Introduced force flag to the git stash clear subcommand.
Date: Tue, 20 Jun 2023 22:54:53 +0300	[thread overview]
Message-ID: <1540e884-08c7-922e-1fd9-65616268c1c9@gmail.com> (raw)
In-Reply-To: <xmqqy1keodjj.fsf@gitster.g>

> I am not sure how much value users would get by requiring "--force",
> though.  I know this was (partly) modeled after "git clean", but
> over there, when the required "--force" is not given, the user would
> give "--dry-run" (or "-n"), and the user will see what would be
> removed if the user gave "--force".  If missing "--force" made "git
> stash clear" show the stash entries that would be lost, then after
> seeing an error message, it would be easier for the user to decide
> if their next move should be to re-run the command with "--force",
> or there are some precious entries and the user is not ready to do
> "stash clear".
>
> But just refusing to run without giving any other information will
> just train the user to give "git stash clear --force" without
> thinking, because getting "because you did not give the required
> --force option, I am not doing anything" is only annoying without
> giving any useful information.


I see, but isn't the same argument apply for git clean? if not adding 
the force flag, the same message as I wrote appear in git clean (I 
copied it from there), and it will exit without any other information, 
hence given your argument, running git clean is also not very useful.


One can argue that git clean --dry-run == git stash list


I suggested in the beginning of this thread to ask the user if he is 
sure he want to proceed (default to no), and only if he wrote y/yes 
proceed with the action (and force will just do it, or requireforce=false).


The reason I suggested it is because when running git stash clear, it 
will remain in the user recent commands, and when the user will navigate 
through the commands history in the terminal, he might accidentally fire 
git stash clear, and this confirmation will be another safeguard against 
this mistake.


Maybe it will be useful for git clean as well for the same reasons.
Also when the user types git clean, I argue he wanted to clean or he did 
it by mistake, and In both scenarios I don't see why making git clean 
just fail will be useful.


So what do you think? Maybe we should present in both clean and clear a 
confirmation message? (only if requireforce=true)


What do you think?


  reply	other threads:[~2023-06-20 19:55 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-15 21:18 [PATCH] stash: added safety flag for stash clear subcommand Nadav Goldstein via GitGitGadget
2022-05-16  3:17 ` Junio C Hamano
2022-05-23  6:12 ` [PATCH v2 0/2] stash clear: " Nadav Goldstein via GitGitGadget
2022-05-23  6:12   ` [PATCH v2 1/2] add-menu: added add-menu to lib objects Nadav Goldstein via GitGitGadget
2022-05-23 20:03     ` Derrick Stolee
2022-05-23 20:35       ` Junio C Hamano
2022-05-23  6:12   ` [PATCH v2 2/2] clean: refector to the interactive part of clean Nadav Goldstein via GitGitGadget
2022-05-23 19:45     ` Derrick Stolee
2022-05-23 19:33   ` [PATCH v2 0/2] stash clear: added safety flag for stash clear subcommand Derrick Stolee
2023-06-20  0:03   ` [PATCH v3] Introduced force flag to the git " Nadav Goldstein via GitGitGadget
2023-06-20  6:25     ` Junio C Hamano
2023-06-20 19:54       ` Nadav Goldstein [this message]
2023-06-20 20:46         ` Junio C Hamano
2023-06-20 21:01         ` Eric Sunshine
2023-06-20 21:42           ` Nadav Goldstein

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=1540e884-08c7-922e-1fd9-65616268c1c9@gmail.com \
    --to=nadav.goldstein96@gmail.com \
    --cc=derrickstolee@github.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=gitster@pobox.com \
    /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).