threads / rfc / 17910

RFC patchgit-shortlog: respect i18n.logOutputEncoding config setting

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

## tl;dr

4 messages between Feb 20, 2009 and Mar 22, 2009. Diffs are folded; open one to read it.

replies: 3people: 2as markdown or json

Miklos Vajna· Feb 20, 2009, 01:12 UTC · lore

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(-)

Show changes to builtin-shortlog.c +7 −1

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

Miklos Vajna· Mar 22, 2009, 11:34 UTC · re: Miklos Vajna · lore

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

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. :-)

Junio C Hamano· Mar 22, 2009, 19:26 UTC · re: Miklos Vajna · lore

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

Miklos Vajna <vmiklos@frugalware.org> writes:

Show 5 quoted lines

> 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?

Miklos Vajna· Mar 22, 2009, 19:47 UTC · re: Junio C Hamano · lore

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

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.