Hi list! Most of our developers use msysgit which stores filenames in
CP1251 encoding. Two of us use cygwin and linux.
When checkout on both linux and cygwin, Russian filenames are garbled.
On Cygwin it even worse, because the conversion of invalid UTF-8 chars
to Unicode, made by Cygwin is irreversible, causing git to miss
the files it've just checked out. Workaround for Cygwin is to change
LANG from "C.UTF-8" to "ru_RU.CP1251". It fixes filenames, but brakes
everything else: log (fixed by i18n.logOutputEncoding), status, show,
diff
Unlike on Cygwin, LANG has no effect for git filenames on Linux. Good
thing, there's no conversion to unicode, so files aren't lost at
checkout.
Question: is there a way to tell git on Linux to use UTF-8 filenames
for the working tree, while storing them in CP1251?
Hi!
On Tue, Aug 2, 2011 at 11:54 AM, Ilya Basin [off-list ref] wrote:
Unlike on Cygwin, LANG has no effect for git filenames on Linux. Good
thing, there's no conversion to unicode, so files aren't lost at
checkout.
LANG has no effect on open() or other system functions on Linux, so
all filenames are created as they were stored in Git, in your case,
it is CP1251.
AFAIK, it should not be difficult to configure CP1251 on Linux. You
generate the required locale and then start xterm with this locale
and specifying some CP1251 font.
I have never done it before, but the following steps seem to work:
# generate CP1251
sudo localedef -c -i ru_RU -f CP1251 ru_RU.CP1251
# make sure that it was generated
# you should see ru_RU.cp1251 in the output
locale -a | grep ru_RU
# start xterm
LANG=ru_RU.cp1251 xterm -fn '-monotype-courier
new-semilight-r-normal--0-0-0-0-c-0-microsoft-cp1251' &
You can try another font. See the output of xlsfonts:
xlsfonts | grep -i cp1251
Question: is there a way to tell git on Linux to use UTF-8 filenames
for the working tree, while storing them in CP1251?
The short answer is no. A more detail answer is that there was
a series of patches that should allow filename conversation:
http://article.gmane.org/gmane.comp.version-control.git/119224
but a proper implementation turned out to be very invasive and
no one seems to care about it very deeply, so it was dropped.
See details here:
http://article.gmane.org/gmane.comp.version-control.git/122860
Dmitry