Re: what should "git clean -n -f [-d] [-x] <pattern>" do?

Junio C Hamano [off-list ref] writes:

Sergey Organov [off-list ref] writes:

quoted

Sergey Organov [off-list ref] writes:

quoted

Junio C Hamano [off-list ref] writes:
..

quoted

...  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