I see both of your points, and I agree adding the flag will only make
users type the flag without thinking.
But I still don't understand why do we need git clean without any flags.
The only users that will run git clean are new users that don't know you
need to run it with -f or experienced users that set clean.requireforce
= false.
Moreover, we can also assume that every user that have
clean.requireforce = true (the default), and ran git clean, did so by
mistake/intended to clean, So why don't we offer him interactive way to
understand the consequences and confirm his action? (and explain about
clean.requireforce like we currently do).
By doing it this way, the change will not effect experienced users
because they either run git clean -f when they need to clean or they set
clean.requireforce = false, and then the change will not apply to them.
This argument is also for stash clear.
Thanks.
On 21/06/2023 0:01, Eric Sunshine wrote:
On Tue, Jun 20, 2023 at 4:05 PM Nadav Goldstein
<nadav.goldstein96@xxxxxxxxx> wrote:
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.
For what it's worth, I had the same reaction as Junio upon reading
this patch; specifically, that it will train users to type "git stash
clear --force" mechanically without thinking, thus won't be much of a
safeguard.
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.
"git clean" is in a rather different (and more severe) boat since file
deletion is irrevocable, whereas a stash thrown away by "git stash
clear" (or "git stash drop") can be recovered (at least until it gets
garbage-collected). So, rather than adding a --force option or an
interactive "yes/no" prompt, perhaps a better approach would be to
have "git stash clear" (and "git stash drop") print out advice
explaining to the user how to recover the dropped stash(es), much like
"git switch" or "git checkout" prints advice explaining how to recover
commits left dangling on a detached head.