From: Sergey Organov <sorganov@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Elijah Newren <newren@gmail.com>, git@vger.kernel.org
Subject: Re: what should "git clean -n -f [-d] [-x] <pattern>" do?
Date: Fri, 26 Jan 2024 15:09:39 +0300 [thread overview]
Message-ID: <87ede4fg8s.fsf@osv.gnss.ru> (raw)
In-Reply-To: <xmqqzfwspmh0.fsf@gitster.g> (Junio C. Hamano's message of "Thu, 25 Jan 2024 23:44:59 -0800")
Junio C Hamano <gitster@pobox.com> writes:
> Sergey Organov <sorganov@gmail.com> writes:
>
>> Sergey Organov <sorganov@gmail.com> writes:
>>
>>> Junio C Hamano <gitster@pobox.com> 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
next prev parent reply other threads:[~2024-01-26 12:09 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-09 20:20 what should "git clean -n -f [-d] [-x] <pattern>" do? Junio C Hamano
2024-01-09 22:04 ` Sergey Organov
2024-01-19 2:07 ` Elijah Newren
2024-01-23 15:10 ` Sergey Organov
2024-01-23 18:34 ` Junio C Hamano
2024-01-24 8:23 ` Sergey Organov
2024-01-24 17:21 ` Junio C Hamano
2024-01-25 17:11 ` Sergey Organov
2024-01-25 17:46 ` Junio C Hamano
2024-01-25 20:27 ` Sergey Organov
2024-01-25 20:31 ` Sergey Organov
2024-01-26 7:44 ` Junio C Hamano
2024-01-26 12:09 ` Sergey Organov [this message]
2024-01-27 10:00 ` Junio C Hamano
2024-01-27 13:25 ` Sergey Organov
2024-01-29 19:40 ` Kristoffer Haugsbakk
2024-01-31 13:04 ` Sergey Organov
2024-01-29 9:35 ` Sergey Organov
2024-01-29 18:20 ` Jeff King
2024-01-29 21:49 ` Sergey Organov
2024-01-30 5:44 ` Jeff King
2024-01-30 5:53 ` Junio C Hamano
2024-02-29 19:07 ` [PATCH] clean: improve -n and -f implementation and documentation Sergey Organov
2024-03-01 13:20 ` Jean-Noël Avila
2024-03-01 14:34 ` Sergey Organov
2024-03-01 15:29 ` Kristoffer Haugsbakk
2024-03-01 18:07 ` Junio C Hamano
2024-03-02 19:47 ` Jean-Noël AVILA
2024-03-02 20:09 ` Sergey Organov
2024-03-02 21:07 ` Junio C Hamano
2024-03-02 23:48 ` Sergey Organov
2024-03-03 9:54 ` Sergey Organov
2024-03-01 18:07 ` Junio C Hamano
2024-03-01 18:30 ` Junio C Hamano
2024-03-01 19:31 ` Sergey Organov
2024-03-02 16:31 ` Junio C Hamano
2024-03-02 19:59 ` Sergey Organov
2024-03-03 9:50 ` [PATCH v2] " Sergey Organov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87ede4fg8s.fsf@osv.gnss.ru \
--to=sorganov@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=newren@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).