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

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

[Miklos Vajna]

As git-shortlog can be used as a filter as well, we do not really have
the encoding info to do a reencode_string(), but in case
i18n.logOutputEncoding is set, we can try to convert to the given value
from utf-8.

Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---

It was just annoying for me that git log respected
i18n.logOutputEncoding, but I still saw unencoded utf-8 in git-shortlog
output. This patches fixes my problem.

Yes, I'm aware that hardwiring that utf-8 value is a bit hackish. But at
least this way the output encoding is correct in case the original
encoding is utf-8, which is true in most cases.

Or do you have a better idea?

 builtin-shortlog.c |    8 +++++++-
 1 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/builtin-shortlog.c b/builtin-shortlog.c
index badd912..cd95858 100644
--- a/builtin-shortlog.c
+++ b/builtin-shortlog.c
@@ -45,6 +45,7 @@ static void insert_one_record(struct shortlog *log,
 	const char *eol;
 	const char *boemail, *eoemail;
 	struct strbuf subject = STRBUF_INIT;
+	char *encoded_name = NULL;
 
 	boemail = strchr(author, '<');
 	if (!boemail)
@@ -84,7 +85,12 @@ static void insert_one_record(struct shortlog *log,
 		snprintf(namebuf + len, room, " <%.*s>", maillen, emailbuf);
 	}
 
-	item = string_list_insert(namebuf, &log->list);
+	if (git_log_output_encoding)
+		encoded_name = reencode_string(namebuf, git_log_output_encoding, "utf-8");
+	if (!encoded_name)
+		encoded_name = xstrdup(namebuf);
+	item = string_list_insert(encoded_name, &log->list);
+	free(encoded_name);
 	if (item->util == NULL)
 		item->util = xcalloc(1, sizeof(struct string_list));
 
-- 
1.6.1.3

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

[Miklos Vajna]

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

On Fri, Feb 20, 2009 at 02:12:38AM +0100, Miklos Vajna <vmiklos@frugalware.org> wrote:
> As git-shortlog can be used as a filter as well, we do not really have
> the encoding info to do a reencode_string(), but in case
> i18n.logOutputEncoding is set, we can try to convert to the given value
> from utf-8.

Should I resend this patch without RFC in the subject?

I just hit this bug again today, then realised that I already posted a
patch for this problem. :-)

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

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

[Junio C Hamano]

Miklos Vajna <vmiklos@frugalware.org> writes:

> On Fri, Feb 20, 2009 at 02:12:38AM +0100, Miklos Vajna <vmiklos@frugalware.org> wrote:
>> As git-shortlog can be used as a filter as well, we do not really have
>> the encoding info to do a reencode_string(), but in case
>> i18n.logOutputEncoding is set, we can try to convert to the given value
>> from utf-8.

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?

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

[Miklos Vajna]

[-- 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 --]