[PATCH] commit: fix pretty-printing of messages with "\nencoding "

Jeff King· Mar 28, 2007, 21:52 UTC · lore

The function replace_encoding_header is given the whole commit buffer, including the commit message. When looking for the encoding header, if none was found in the header, it would locate any line in the commit message matching "\nencoding " and remove it.

Instead, we now make sure to search only to the end of the header.

Signed-off-by: Jeff King <peff@peff.net>
---
You can see the bug by doing this:
  git-commit -m 'encoding foo'
  git-show
and getting a blank log message (unless, of course, you're using a
non-utf8 commit encoding, in which case you will actually have an
encoding header).

I wonder, though, if this function before or after is actually correct; if there is no encoding header, we exit the function immediately. But if we are changing the encoding from utf8 to a non-utf8 value, we presumably should continue and actually insert the new encoding header.

The searching could potentially be refactored to share code with get_header; however, either the interface gets a little hairy, or you have to repeat a few strlen()s, and I seem to recall a recent effort to reduce such calls in critical paths (which I think this probably is). The implementation here isn't ugly, anyway.

 commit.c |    7 +++++--
 1 files changed, 5 insertions(+), 2 deletions(-)

Show changes to commit.c +5 −2

diff --git a/commit.c b/commit.c
index a4f2e74..754d1b8 100644
--- a/commit.c
+++ b/commit.c
@@ -654,6 +654,7 @@ static char *get_header(const struct commit *commit, const char *key)
 static char *replace_encoding_header(char *buf, const char *encoding)
 {
 	char *encoding_header = strstr(buf, "\nencoding ");
+	char *header_end = strstr(buf, "\n\n");
 	char *end_of_encoding_header;
 	int encoding_header_pos;
 	int encoding_header_len;
@@ -661,8 +662,10 @@ static char *replace_encoding_header(char *buf, const char *encoding)
 	int need_len;
 	int buflen = strlen(buf) + 1;
 
-	if (!encoding_header)
-		return buf; /* should not happen but be defensive */
+	if (!header_end)
+		header_end = buf + buflen;
+	if (!encoding_header || encoding_header >= header_end)
+		return buf;
 	encoding_header++;
 	end_of_encoding_header = strchr(encoding_header, '\n');
 	if (!end_of_encoding_header)

-- 
1.5.1.rc2.636.g7ca6fa-dirty

Junio C Hamano· Mar 28, 2007, 22:10 UTC · re: Jeff King · lore

Re: [PATCH] commit: fix pretty-printing of messages with "\nencoding "

Jeff King <peff@peff.net> writes:

> I wonder, though, if this function before or after is actually correct;
> if there is no encoding header, we exit the function immediately. But if
> we are changing the encoding from utf8 to a non-utf8 value, we
> presumably should continue and actually insert the new encoding header.

The function is correct; the only reason it may recode to non-utf8 is the user (or Porcelain such as qgit or gitk) explicitly asked to do so -- from the final output they will get the message in user-native encoding and without the extra encoding header, thus we retain the backward compatible behaviour before the re-encoding feature was introduced.

Jeff King· Mar 28, 2007, 22:15 UTC · re: Junio C Hamano · lore

Re: [PATCH] commit: fix pretty-printing of messages with "\nencoding "

On Wed, Mar 28, 2007 at 03:10:07PM -0700, Junio C Hamano wrote:

Show 6 quoted lines

> The function is correct; the only reason it may recode to
> non-utf8 is the user (or Porcelain such as qgit or gitk)
> explicitly asked to do so -- from the final output they will get
> the message in user-native encoding and without the extra
> encoding header, thus we retain the backward compatible
> behaviour before the re-encoding feature was introduced.

I see. But then why do we not simply strip the encoding header entirely, and return in native format? Why do we insert a new encoding header _only_ when there was one previously?

-Peff

patchcommit: fix pretty-printing of messages with "\nencoding "