Re: pre-v2.34.0-rc0 regressions: 'git log' has a noisy iconv() warning

Jeff King [off-list ref] writes:

The firehose of warnings for "git log --encoding=nonsense" was known and
discussed in fd680bc558 (logmsg_reencode(): warn when iconv() fails,
2021-08-27). It's ugly for sure, but I'm still OK with it for the
reasoning there: your next step is to fix the --encoding argument you
gave. Whether you saw one line of warning or many is not that important,
IMHO. Giving a single more sensible warning ("your encoding 'nonsense'
isn't valid") would be better, but I think it's hard to do without
creating other problems.

But the most compelling argument against warning at all is the case you
gave earlier: that there may be historical garbage commits, and you
can't get rid of them, so being warned constantly that we're not going
to show or grep them correctly is just annoying. And that is true
whether the user sees one warning or a hundred.

Is it really a "firehose"?  I won't use the word for one warning
message per commit in the output of "git log --encoding=nonsense".

If you are running "git log --oneline", it may indeed be annoying to
double the number of lines shown, and indeed

    $ git log --oneline --encoding=US-ASCII -4 ab/doc-lint
    warning: unable to reencode commit to 'US-ASCII'
    414abf159f docs: fix linting issues due to incorrect relative section order
    warning: unable to reencode commit to 'US-ASCII'
    ea8b9271b1 doc lint: lint relative section order
    warning: unable to reencode commit to 'US-ASCII'
    cafd9828e8 doc lint: lint and fix missing "GIT" end sections
    warning: unable to reencode commit to 'US-ASCII'
    d2c9908076 doc lint: fix bugs in, simplify and improve lint script

is indeed annoying, as everything that is _shown_ ought to be
presentable in US-ASCII.  This observation makes us realize an
obvious approach to improve over the current behaviour without
losing the warning when it matters, but I think the required code
change, to first split the commit message into pieces (which roughly
corresponds to the atoms in the --format= placeholder language) and
reencode only these pieces that will be shown, may be too involved
to be worth the effort.

So while I do hate to have Git just silently ignore errors, probably the
original behavior is the least-bad thing, and we should just revert
fd680bc558 (logmsg_reencode(): warn when iconv() fails, 2021-08-27). We
probably want to salvage the documentation change (minus the "along with
a warning") part.

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?