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

[Miklos Vajna <vmiklos@frugalware.org>]

[-- Attachment #1: Type: text/plain, Size: 1382 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]