Re: Really noisy encoding warnings post-v2.33.0

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Oct 9, 2021, 01:29 UTC
Message-ID: <87ee8vm19j.fsf@evledraar.gmail.com>
In-Reply-To: <87ily7m1mv.fsf@evledraar.gmail.com>

On Sat, Oct 09 2021, Ævar Arnfjörð Bjarmason wrote:

Show 20 quoted lines

> On Fri, Aug 27 2021, Jeff King wrote:
>
> $subject because I think we should really consider backing this out
> before it gets to a real release.
>
> I ran into this while testing the grep coloring patch[1] (but it's
> unrelated). Before this commit e.g.:
>
>     LC_ALL=C ~/g/git/git -P -c i18n.commitEncoding=ascii log --author=Ævar -100|wc -l
>     28333
>
> So ~3k lines for my last 100 commits, but then:
>
>     $ LC_ALL=C ~/g/git/git -P -c i18n.commitEncoding=ascii log --author=Ævar -100 2>&1|grep -c ^warning
>     299
>
> At first I thought it was spewing warnings for every failed re-encoded
> line in some cases, because I get hundreds at a time sometimes, but it's
> because stderr and stdout I/O buffering is different (a common
> case). Adding a "fflush(stderr)" "fixes" that.

It's partially that, but also more pathologically:

    $ git -P -c i18n.commitEncoding=ascii log --author=doesnotexist -1 | wc -l
    0
    $ git -P -c i18n.commitEncoding=ascii log --author=doesnotexist -1 2>&1 |wc -l
    6688

I.e. even if we don't end up emitting anything we'll warn, of course we might not match *because* we failed, e.g. if you had a non-ascii --grep string, but in this case it's rather noisy.

Show 6 quoted lines

> But anyway, I think we've got a lot of users who say *do* want to
> reencode something from say UTF-8 to latin1, but then might have the
> occasional non-latin1 representable data. The old behavior of silently
> falling back is going to be much better for those users, or maybe show
> one warning at the end or something, if you feel it really needs to be
> kept.

Re: *Really* noisy encoding warnings post-v2.33.0

Re: Really noisy encoding warnings post-v2.33.0