Junio C Hamano [off-list ref] writes:
I would say that the patch is an improvement from the current
code so it should hit 'master'; I was a bit busy lately and then
am sick, and also we are post -rc1 freeze now and I was being
cautious, just in case some nacks from more informed parties
arrive late.
Sorry for the late nack, but it turns out that this patch breaks diff
output on the Wine server for files that are not utf-8.
The cause is apparently that decode_utf8() returns undef for invalid
sequences instead of substituting a replacement char like
decode("utf8") does.
That may be considered an Encode bug since we are running a fairly old
version (1.99, coming with Debian 3.1), but I'd rather not upgrade
perl on the server. Could the patch be reverted, or done differently?
--
Alexandre Julliard
julliard@winehq.org
On Friday 01 June 2007 16:45:31 Alexandre Julliard wrote:
Junio C Hamano [off-list ref] writes:
quoted
I would say that the patch is an improvement from the current
code so it should hit 'master'; I was a bit busy lately and then
am sick, and also we are post -rc1 freeze now and I was being
cautious, just in case some nacks from more informed parties
arrive late.
Sorry for the late nack, but it turns out that this patch breaks diff
output on the Wine server for files that are not utf-8.
Isn't UTF-8 default even for Linux kernel now?
The cause is apparently that decode_utf8() returns undef for invalid
sequences instead of substituting a replacement char like
decode("utf8") does.
That may be considered an Encode bug since we are running a fairly old
version (1.99, coming with Debian 3.1), but I'd rather not upgrade
perl on the server. Could the patch be reverted, or done differently?
Sorry but thats too old. Of course I am not the maintainer of GIT so its not
for me to decide but well as David Woodhouse puts it, please join us in 21st
century and start using UTF-8.
/ismail
--
Perfect is the enemy of good
On Fri, 1 Jun 2007, Alexandre Julliard wrote:
The cause is apparently that decode_utf8() returns undef for invalid
sequences instead of substituting a replacement char like
decode("utf8") does.
That may be considered an Encode bug since we are running a fairly old
version (1.99, coming with Debian 3.1), but I'd rather not upgrade
perl on the server. Could the patch be reverted, or done differently?
Could you put modern (without this decode_utf8 bug) version of Encode.pm
in the directory with gitweb.cgi, so gitweb uses new local version and
not the one that is installed system-wide?
--
Jakub Narebski
Poland