Re: [RFC/PATCH] git-shortlog: respect i18n.logOutputEncoding config setting

From: Miklos Vajna <vmiklos@frugalware.org>
Date: Mar 22, 2009, 19:47 UTC
Message-ID: <20090322194708.GP27459@genesis.frugalware.org>
In-Reply-To: <7v7i2h5pfh.fsf@gitster.siamese.dyndns.org>

On Sun, Mar 22, 2009 at 12:26:58PM -0700, Junio C Hamano <gitster@pobox.com> wrote:

Show 6 quoted lines

> It is unclear what you want to say in these for lines.  Do you mean "when
> used to generate logs by itself this patch improves the behaviour by
> making the output consistent with what "git log" does, but it does the
> same mangling when used as a filter without knowing the log encoding and
> potentially screw people over who have been depending on it not to convert
> the encoding"?  Or something else?

Not exactly - let me rephrase:

Normally we can do a reencode_string() because we know the encoding of the commit and we know the wished output encoding. Given that git-shortlog can be a filter as well, we don't know the encoding of the input, but we know the wished output encoding. So what we can do is to _try_ to encode from utf8 to the wished encoding, and if that fails, just don't convert anything. The result is correct, because:

1) If git-shortlog is a filter, then git-log already does the encoding,
the encoding will fail in git-shortlog so the original input will be
shown.

2) In the other case git-shoftlog can just do the converion.

At least I tested the case with utf8 author names and a latin2 terminal and both the 'git log rev.. | git shortlog' and the 'git shortlog rev..' output was correct, while git.git's master shows the correct output only in the first case.