Sergey Organov <sorganov@xxxxxxxxx> writes:
>> The reason for the behaviour can be explained this way:
>>
>> * "git clean" (with neither -i nor -n. The user wants the default
>> mode that has no built-in protection will be stopped without -f.
>>
>> * "git clean -n". The user wants the dry-run mode that has its own
>> protection, i.e. being always no-op to the files, so there is no
>> need to fail here for the lack of "-f".
>>
>> * "git clean --interactive". The user wants the interactive mode
>> that has its own protection, i.e. giving the end-user a chance to
>> say "oh, I didn't mean to remove these files, 'q'uit from this
>> mistake", so there is no need to fail here for the lack of "-f".
>
> Well, if we remove -i from error message as well, then yes, this makes
> sense.
> ...
> I then suggest to consider to remove mention of -i from
> clean.requireForce description as well.
The follow-up patch you just reviewed in the other thread does
exactly that.
This is a tangent, but before finalizing the version that complains
"clean.requireForce is in effect and you did not give me -f" without
mentioning "-i" or "-n", I asked gemini.google.com to proofread the
patch and and one of its suggestion was to use this:
"clean.requireForce is true. Use -f to override, or consider
using -n (dry-run) or -i (interactive) for a safer workflow."
as a possibly cleaner message. It is the opposite of what both of
us concluded to be good in this exchange, but in some sense, it does
sound more helpful to end users, which I somehow found amusing.
