Junio C Hamano <gitster@xxxxxxxxx> writes: > Sergey Organov <sorganov@xxxxxxxxx> writes: > >> Sergey Organov <sorganov@xxxxxxxxx> writes: >> >>> Junio C Hamano <gitster@xxxxxxxxx> writes: >>> .. >>>> ... If the original semantics >>>> were "you must force with -f to do anything useful", instead of "you >>>> must choose either forcing with -f or not doing with -n", then it >>>> would have led to the above behaviour. >>> ... >>> If we agree on the behavior above for sane "dry run"... > > Not so fast. I said "if the original semantics were ... then it > would have led to the above behaviour". As the original semantics > were not, that conclusion does not stand. OK, fine, then my point is that the original semantics if flawed. > > The "-n" option here were not added primarily as a dry-run option, > and haven't been treated as such forever. As can be seen by the > "you must give either -f or -n option, and it is an error to give > neither" rule, from the end-user's point of view, it is a way to say > "between do-it (-f) and do-not-do-it (-n), I choose the latter for > this invocation". Yep, and in my opinion this is even more a mistake than "-f -f". > And in that context, an attempt to make "-f -f" > mean a stronger form of forcing than "-f" was a mistake, because it > makes your "I want to see what happens if I tried that opration that > requires the stronger force" request impossible. I believe this just emphasizes the original mistake of "-n" design meaning something else than simple "dry run". > > And there are two equally valid ways to deal with this misfeature. I rather see two almost independent misfeatures here, so I believe both are to be addressed. > > One is to admit that "-f -f" was a mistake (which I already said), > and a natural consequence of that admission is to introduce a more > specific "in addition to what you do usually, this riskier operation > is allowed" option (e.g., --nested-repo). This addresses one of the two deficiencies I see, yes. > This leads to a design that matches real world usage better, even if > we did not have the "how to ask dry-run?" issue, because in the real > world, when there are multiple "risky" things you may have to > explicitly ask to enable, these things do not necessarily form a nice > linear "riskiness levels" that you can express your risk tolerance > with the number of "-f" options. When you need to add special > protection for a new case other than "nested repo", for example, the > "riskiness levels" design may need to place it above the "nested repo" > level of riskiness and may require the user to give three "-f" > options, but that would make it impossible to protect against nuking > of nested repos while allowing only that newly added case. By having > more specific "this particular risky operation is allowed", "-f" can > still be "between do-it and do-not-do-it, I choose the former", Yep, makes sense. > and the "--nested-repo" (and other options to allow specific risky > operations we add in the future) would not have to have funny > interactions with "-n". Yep, but it still leaves "-n" being defective, as it for whatever reason surprisingly clashes with "-f". I believe it shouldn't. > The other valid way is to treat the use of the "riskiness levels" to > specify what is forced still as a good idea. If one comes from that > position, the resulting UI would be consistent with what you have > been advocating for. One or more "-f" will specify what kind of > risky stuff are allowed, and "-n" will say whether the operation > gets carried out or merely shown what would happen if "-n" weren't > there. I'm not arguing in favor of "-f -f". My point is that even if you fix "-f -f", "-n" deficiency will still cry for fixing. > > It is just that I think "riskiness levels" I did in a0f4afbe (clean: > require double -f options to nuke nested git repository and work > tree, 2009-06-30) was an utter mistake, and that is why I feel very > hesitant to agree with the design that still promotes it. Again, I'm not arguing in favor of "-f -f", I'm rather neutral about it. I'm still arguing in favor of fixing "-n", and I believe a fix is needed independently from decision about "-f -f". Thanks, -- Sergey Organov
