git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH v5 5/5] pretty: user format ignores i18n.logOutputEncoding setting

From
Junio C Hamano <gitster@pobox.com>
Date
Jun 20, 2013, 20:37 UTC
Message-ID
<7v8v24selt.fsf@alter.siamese.dyndns.org>
In-Reply-To
<ed75c8cbcfbbac336e2384e2f566e42264154918.1371720245.git.Alex.Crezoff@gmail.com>
Alexey Shumkin <Alex.Crezoff@gmail.com> writes:
Subject: Re: [PATCH v5 5/5] pretty: user format ignores i18n.logOutputEncoding setting
That is a statement of fact, and does not tell much to the reader.

I think you are saying that in the current implementation, logoutputencoding is not honored in user format, that it is a bug that needs to be fixed (as opposed to "that is by design, the scripts that read from --format='' is responsible for doing the conversion"), and that this patch fixes it.

So
	pretty: --format output should honor logOutputEncoding

or something? At least it says what is the _desired_ outcome with "should", hints that the status-quo is different from that desired outcome and implies that this is a patch to fix it.

The "Subject" line is very important as that is the only thing we see in many summarizing output format, e.g. shortlog, cover letter and merge message.

Show 47 quoted lines
> The following two commands are expected to give the same output to a terminal:
>
> 	$ git log --oneline --no-color
> 	$ git log --pretty=format:'%h %s'
>
> However, the former pays attention to i18n.logOutputEncoding
> configuration, while the latter does not when it format "%s".
> Log messages written in an encoding i18n.commitEncoding which differs
> from terminal encoding are shown corrupted with the latter even
> when i18n.logOutputEncoding and terminal encoding are the same.
>
> The same corruption is true for
> 	$ git diff --submodule=log
> and
> 	$ git rev-list --pretty=format:%s HEAD
> and
> 	$ git reset --hard
>
> Signed-off-by: Alexey Shumkin <Alex.Crezoff@gmail.com>
> ---
>  builtin/reset.c                  |  8 ++++++--
>  builtin/rev-list.c               |  1 +
>  builtin/shortlog.c               |  1 +
>  log-tree.c                       |  1 +
>  submodule.c                      |  3 +++
>  t/t4041-diff-submodule-option.sh | 10 +++++-----
>  t/t4205-log-pretty-formats.sh    | 34 +++++++++++++++++-----------------
>  t/t6006-rev-list-format.sh       |  8 ++++----
>  t/t7102-reset.sh                 |  2 +-
>  9 files changed, 39 insertions(+), 29 deletions(-)
>
> diff --git a/builtin/reset.c b/builtin/reset.c
> index 6032131..b23ed63 100644
> --- a/builtin/reset.c
> +++ b/builtin/reset.c
> @@ -92,11 +92,15 @@ static int reset_index(const unsigned char *sha1, int reset_type, int quiet)
>  
>  static void print_new_head_line(struct commit *commit)
>  {
> -	const char *hex, *body;
> +	const char *hex, *body, *encoding;
>  
>  	hex = find_unique_abbrev(commit->object.sha1, DEFAULT_ABBREV);
>  	printf(_("HEAD is now at %s"), hex);
> -	body = strstr(commit->buffer, "\n\n");
> +	encoding = get_log_output_encoding();
> +	body = logmsg_reencode(commit, NULL, encoding);
> +	if (!body)
> +		body = commit->buffer;

Does this happen? I thought body, without an error, can be the same as commit->buffer.

> +	body = strstr(body, "\n\n");
>  	if (body) {
>  		const char *eol;
>  		size_t len;

Do we have a leak here? body may point at a new piece of memory logmsg_reencode() have allocated to hold the UTF-8 version of your 8859-5 message in commit->buffer.

It would be more like this, no?
diff --git a/builtin/reset.c b/builtin/reset.c
index 6032131..8d22ffe 100644
--- a/builtin/reset.c
+++ b/builtin/reset.c
@@ -92,11 +92,13 @@ static int reset_index(const unsigned char *sha1, int reset_type, int quiet)
 
 static void print_new_head_line(struct commit *commit)
 {
-	const char *hex, *body;
+	const char *hex, *body, *msg, *encoding; 
 
 	hex = find_unique_abbrev(commit->object.sha1, DEFAULT_ABBREV);
 	printf(_("HEAD is now at %s"), hex);
-	body = strstr(commit->buffer, "\n\n");
+
+	msg = logmsg_reencode(commit, NULL, get_log_output_encoding());
+	body = strstr(msg, "\n\n");
 	if (body) {
 		const char *eol;
 		size_t len;
@@ -107,6 +109,7 @@ static void print_new_head_line(struct commit *commit)
 	}
 	else
 		printf("\n");
+	logmsg_free(msg, commit);
 }
 
 static void update_index_from_diff(struct diff_queue_struct *q,
Previous: Alexey ShumkinNext: Junio C Hamano
Message 30 of 82 in “pretty: Add failing tests: user format ignores i18n.logOutputEncoding setting”
  1. 1/2 pretty: Add failing tests: user format ignores i18n.logOutputEncoding settingAlexey Shumkin, Sep 20, 2011
  2. 2/2 pretty: user format ignores i18n.logOutputEncoding settingAlexey Shumkin, Sep 20, 2011
  3. Junio C HamanoSep 20, 2011
  4. Alexey ShumkinSep 20, 2011
  5. 0/4 Reroll patches against v1.8.1.1Alexey Shumkin, Jan 24, 2013
  6. 1/4 t6006 (rev-list-format): don't hardcode SHA-1 in expected outputsAlexey Shumkin, Jan 24, 2013
  7. Junio C HamanoJan 24, 2013
  8. Alexey ShumkinJan 25, 2013
  9. Alexey ShumkinJan 25, 2013
  10. Junio C HamanoJan 25, 2013
  11. Alexey ShumkinJan 25, 2013
  12. 2/4 t7102 (reset): refactoring: don't hardcode SHA-1 in expected outputsAlexey Shumkin, Jan 24, 2013
  13. Junio C HamanoJan 24, 2013
  14. Alexey ShumkinJan 25, 2013
  15. 3/4 pretty: Add failing tests: user format ignores i18n.logOutputEncoding settingAlexey Shumkin, Jan 24, 2013
  16. Junio C HamanoJan 24, 2013
  17. Alexey ShumkinJan 25, 2013
  18. Junio C HamanoJan 24, 2013
  19. Alexey ShumkinJan 25, 2013
  20. 4/4 pretty: user format ignores i18n.logOutputEncoding settingAlexey Shumkin, Jan 24, 2013
  21. 0/5 Reroll patches against v1.8.3.1Alexey Shumkin, Jun 20, 2013
  22. 1/5 t6006 (rev-list-format): don't hardcode SHA-1 in expected outputsAlexey Shumkin, Jun 20, 2013
  23. Junio C HamanoJun 20, 2013
  24. 2/5 t7102 (reset): don't hardcode SHA-1 in expected outputsAlexey Shumkin, Jun 20, 2013
  25. 3/5 t4205 (log-pretty-formats): don't hardcode SHA-1 in expected outputsAlexey Shumkin, Jun 20, 2013
  26. Junio C HamanoJun 20, 2013
  27. 4/5 pretty: Add failing tests: user format ignores i18n.logOutputEncoding settingAlexey Shumkin, Jun 20, 2013
  28. Junio C HamanoJun 20, 2013
  29. 5/5 pretty: user format ignores i18n.logOutputEncoding settingAlexey Shumkin, Jun 20, 2013
  30. Junio C HamanoJun 20, 2013
  31. Junio C HamanoJun 20, 2013
  32. 0/5 Reroll patches against v1.8.3.1Alexey Shumkin, Jun 25, 2013
  33. 1/5 t6006 (rev-list-format): don't hardcode SHA-1 in expected outputsAlexey Shumkin, Jun 25, 2013
  34. 2/5 t7102 (reset): don't hardcode SHA-1 in expected outputsAlexey Shumkin, Jun 25, 2013
  35. 3/5 t4205 (log-pretty-formats): don't hardcode SHA-1 in expected outputsAlexey Shumkin, Jun 25, 2013
  36. 4/5 pretty: Add failing tests: --format output should honor logOutputEncodingAlexey Shumkin, Jun 25, 2013
  37. 5/5 pretty: --format output should honor logOutputEncodingAlexey Shumkin, Jun 25, 2013
  38. Junio C HamanoJun 25, 2013
  39. Alexey ShumkinJun 26, 2013
  40. Junio C HamanoJun 26, 2013
  41. 0/5 Reroll patches against v1.8.3.1Alexey Shumkin, Jun 26, 2013
  42. 1/5 t6006 (rev-list-format): don't hardcode SHA-1 in expected outputsAlexey Shumkin, Jun 26, 2013
  43. 2/5 t7102 (reset): don't hardcode SHA-1 in expected outputsAlexey Shumkin, Jun 26, 2013
  44. 3/5 t4205 (log-pretty-formats): don't hardcode SHA-1 in expected outputsAlexey Shumkin, Jun 26, 2013
  45. 4/5 pretty: Add failing tests: --format output should honor logOutputEncodingAlexey Shumkin, Jun 26, 2013
  46. Johannes SixtJul 1, 2013
  47. Alexey ShumkinJul 1, 2013
  48. Johannes SixtJul 2, 2013
  49. Alexey ShumkinJul 3, 2013
  50. 5/5 pretty: --format output should honor logOutputEncodingAlexey Shumkin, Jun 26, 2013
  51. Junio C HamanoJun 26, 2013
  52. 0/5 Reroll patches against Git v1.8.3.2Alexey Shumkin, Jul 1, 2013
  53. 1/5 t6006 (rev-list-format): don't hardcode SHA-1 in expected outputsAlexey Shumkin, Jul 1, 2013
  54. 2/5 t7102 (reset): don't hardcode SHA-1 in expected outputsAlexey Shumkin, Jul 1, 2013
  55. 3/5 t4205 (log-pretty-formats): don't hardcode SHA-1 in expected outputsAlexey Shumkin, Jul 1, 2013
  56. 4/5 pretty: Add failing tests: --format output should honor logOutputEncodingAlexey Shumkin, Jul 1, 2013
  57. Johannes SixtJul 2, 2013
  58. 5/5 pretty: --format output should honor logOutputEncodingAlexey Shumkin, Jul 1, 2013
  59. Junio C HamanoJul 2, 2013
  60. Alexey ShumkinJul 3, 2013
  61. Junio C HamanoJul 3, 2013
  62. 0/5 Incremental updates against 'next' branchAlexey Shumkin, Jul 4, 2013
  63. 1/5 t4041, t4205, t6006, t7102: use iso8859-1 rather than iso-8859-1Alexey Shumkin, Jul 4, 2013
  64. Junio C HamanoJul 5, 2013
  65. Alexey ShumkinJul 5, 2013
  66. Junio C HamanoJul 5, 2013
  67. Alexey ShumkinJul 5, 2013
  68. Junio C HamanoJul 5, 2013
  69. 2/5 t4205: revert back single quotesAlexey Shumkin, Jul 4, 2013
  70. Junio C HamanoJul 5, 2013
  71. 3/5 t4205, t6006, t7102: make functions more readableAlexey Shumkin, Jul 4, 2013
  72. Junio C HamanoJul 5, 2013
  73. Alexey ShumkinJul 5, 2013
  74. Junio C HamanoJul 5, 2013
  75. Alexey ShumkinJul 5, 2013
  76. Junio C HamanoJul 5, 2013
  77. 4/5 t6006: add two more tests for the case i18n.commitEncoding is not setAlexey Shumkin, Jul 4, 2013
  78. Junio C HamanoJul 5, 2013
  79. Junio C HamanoJul 5, 2013
  80. Alexey ShumkinJul 5, 2013
  81. Junio C HamanoJul 5, 2013
  82. 5/5 t4205: avoid using `sed`Alexey Shumkin, Jul 4, 2013

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.