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

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

[Jeff King]

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

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

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

[Junio C Hamano]

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.

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

[Jeff King]

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

> 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