Re: [PATCH 4/4] Only re-encode certain parts in commit object, not the whole

From: Jeff King <peff@peff.net>
Date: Feb 21, 2012, 18:25 UTC
Message-ID: <20120221182559.GB32668@sigill.intra.peff.net>
In-Reply-To: <1329834292-2511-4-git-send-email-pclouds@gmail.com>

On Tue, Feb 21, 2012 at 09:24:52PM +0700, Nguyen Thai Ngoc Duy wrote:

Show 7 quoted lines

> Commit object has its own format, which happens to be in ascii, but
> not really subject to re-encoding.
> 
> There are only four areas that may be re-encoded: author line,
> committer line, mergetag lines and commit body.  Encoding of tags
> embedded in mergetag lines is not decided by commit encoding, so leave
> it out and consider it binary.

Is this worth the effort? Yes, re-encoding the ASCII bits of the commit object is unnecessary. But do we actually handle encodings that are not ASCII supersets? IOW, I could see the point if this is making it possible to hold utf-16 names and messages in your commits (though why you would want to do so is beyond me...). But my understanding is that this is horribly broken anyway by other parts of the code. And even looking at your code below:

Show 11 quoted lines

> +static char *reencode_commit(const char *buffer,
> +			     const char *out_enc, const char *in_enc)
> +{
> +	struct strbuf out = STRBUF_INIT;
> +	struct strbuf buf = STRBUF_INIT;
> +	char *reencoded, *s, *e;
> +
> +	strbuf_addstr(&buf, buffer);
> +
> +	s = strstr(buf.buf, "\nauthor ");
> +	assert(s != NULL);

Wouldn't this assert trigger in the presence of encodings which contain ASCII NUL (e.g., wide encodings like utf-16)?

Is there an encoding you have in mind which would be helped by this?

-Peff