Junio C Hamano <gitster@xxxxxxxxx> writes:
> Matthieu Moy <Matthieu.Moy@xxxxxxxxxxxxxxx> writes:
>
>> The nice thing with the confirmation dialog is that it shows the list
>> before asking (and unlike 'rm -i', it asks only once).
>
> I wouldn't object to having "clean -i", which automatically defeats
> the requireforce option.
>
> As to a huge single list you have to approve or reject as a whole, I
> am on the fence. When running "rm -i", I often wished to see
> something like that, but I am fairly sure that I'll call it unusable
> the first time I see a list with a few items I want to keep while
> removing all others.
Elaborating on this a bit more, hoping it would help people who want
to design the "--confirm-before-doing" option...
The primary reason I think the user will find "We are going to
remove these. OK?" irritating is that most of the time, there are
only a few items that the user would want to keep.
$ rm --confirm-before-doing -r path
... list of three dozens of items, among which
... there may be two items that should be kept
Remove all? [Y/n]
After seeing this prompt and saying 'n', the user would _not_ thank
the command for reminding about these precious two items, because
the only next step available to the user is to remove the remaining
34 items manually.
"Confirm in bulk before doing" feature can become useful if it had a
"line item veto" option in the confirmation time. The interaction
then could go like this:
$ rm --confirm-before-doing -r path
path/foo path/frotz/nitfol path/sotto
path/bar path/frotz/xyzzy path/trail
... ... ...
Remove (list items you want to keep)? path/frotz
and the user could instruct it to remove everything other than those
inside path/fortz. If the user do not want to remove anything,
there is an option to ^C out of the command.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html