On Sun, Feb 01, 2009 at 10:48:51PM -0800, Junio C Hamano wrote:
> > I do not know what encoding the author is at that point, but if you cannot
> > be sure that it is UTF-8, using utf8_strwidth() is just as wrong as the
> > current code, IMHO.
>
> That is true, but then we are not losing anything.
>
> This codepath is not about the payload (the contents of the files) but the
> author name part of the commit log message, and UTF-8 would probably be
> the only sensible encoding to standardize on.
>
> If your project uses UTF-8 for everybody, great, we will align them better
> than we did before. If not, sorry, you will get a different misaligned
> names.
>
> That assumes utf8_width() does not barf when fed an invalid byte sequence,
> but I did not think it is that fragile (I didn't actually audit the
> codepath, though).
We should be able to know the encoding (we call reencode_commit_message,
but we don't bother to save the result). It should be trivial to do:
int strwidth(const char *s, const char *encoding)
{
if (!strcmp(encoding, "utf-8"))
return utf8_strwidth(s);
/* ideally, else if (some_other_encoding_family) */
else
return strlen(s);
}
Then utf-8 is fixed, and other encodings keep identical behavior (and
don't even waste cycles on utf-8 decoding). And it should be obvious to
anyone who wants to add a width detector for their pet encoding where it
should go.
-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
