On Sun, Mar 22, 2009 at 12:26:58PM -0700, Junio C Hamano <gitster@xxxxxxxxx> 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:
pgpwWVwnAtwlE.pgp
Description: PGP signature
