Jeff King [off-list ref] writes:
quoted
I am all for making it convenient to squelch, but it would be sad to
lose the convenient way to notice possible misencoding in recent
commits. Or can we have a command line option and pass it through
the callchain, or would that be too involved?
Do you mean a command-line option to squelch the warnings? I think it
would not be too hard to do it as a config option (which is probably
what you'd want anyway, since historical commits would come up over and
over again).
Adding a "git -c please.be.verbose.on.encoding.errors=true" is
sufficient for those who want to diagnose, but that is not very
discoverable. Swapping the polarity and making it verbose by
default, with a knob to squelch, may be more practical from that
point of view.
On Thu, Oct 28, 2021 at 12:02:23PM -0700, Junio C Hamano wrote:
Jeff King [off-list ref] writes:
quoted
quoted
I am all for making it convenient to squelch, but it would be sad to
lose the convenient way to notice possible misencoding in recent
commits. Or can we have a command line option and pass it through
the callchain, or would that be too involved?
Do you mean a command-line option to squelch the warnings? I think it
would not be too hard to do it as a config option (which is probably
what you'd want anyway, since historical commits would come up over and
over again).
Adding a "git -c please.be.verbose.on.encoding.errors=true" is
sufficient for those who want to diagnose, but that is not very
discoverable. Swapping the polarity and making it verbose by
default, with a knob to squelch, may be more practical from that
point of view.
Right, it definitely has to be on by default or it will accomplish
nothing. I was just asking about "config versus command-line".
And I suppose that does not really make implementation that much easier
or harder. What makes it easy is if we accept a big global variable and
do not have to pass it down through the call-stack.
-Peff