Thread (1 message) 1 message, 1 author, 2024-03-02

Re: [PATCH] clean: improve -n and -f implementation and documentation

From: Sergey Organov <hidden>
Date: 2024-03-02 23:49:00

Junio C Hamano [off-list ref] writes:
Sergey Organov [off-list ref] writes:
quoted
quoted
Oh, sorry, I misinterpreted the patch. But yet, I'm not sure that
specifying that this is the default or not is really useful. If the
configuration was set to true, it is was a no-op. If set to false, no
message will appear.
I'm not sure either, and as it's not the topic of this particular patch,
I'd like to delegate the decision on the issue.
It is very much spot on the topic of simplifying and clarifying the
code to unify these remaining two messages into a single one.
I'm inclined to be more against merging than for it, as for me it'd be
confusing to be told that a configuration variable is set to true when I
didn't set it, nor there is any way to figure where it is set, because
in fact it isn't, and it's rather the default that is in use.

Overall, to me the messages are fine as they are (except -n that doesn't
belong there), I don't see compelling reason to hide information from
the user, and thus I won't propose patch that gets rid of one of them.
And involving the --interactive that allows users a chance to
rethink and refrain from removing some to the equation would also be
worth doing in the same topic,
Worth doing what? I'm afraid I lost the plot here, as --interactive
still looks fine to me.
even though it might not fit your immediate agenda of crusade against
--dry-run.
I'm hopefully crusading for --dry-run, not against, trying to get rid of
the cause of the original confusion that started -n/-f controversy.

Thanks,
-- Sergey Organov
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help