2013/4/27 Junio C Hamano <gitster@xxxxxxxxx>: > 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. Agree. I will send a reroll latter. -- Jiang Xin -- 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