Question

As you probably know, Git Bash doesn’t support non-latin characters. That results in multiple failures while creating and using SSH keys (since the paths are russian).

Is there a workaround?

Answer 1

It entirely depends on where does your HOME point to?

See Issue 491:

To sum up my tests, if the Windows user name has non-ASCII characters:

1. If the HOME environment variable is set to an ASCII path, and that path exists, Git Bash finds it (so that is one possible workaround).

2. If there is no HOME environment variable and the HOME constant in “git/etc/profile” is set to an ASCII path, and that path exists, Git Bash finds it. The behaviour seems to be exactly the same as in 1.

3. If the HOME environment variable is set to a non-ASCII path (like “C:\Höme“), Git Bash doesn’t find it. It attempts to fall back on the C:\Documents and settings\[User Name] directory, but it fails to find it because it mangles the non-ASCII characters in the [User Name].

4. After the HOME system environment variable (or the constant in git/etc/profile) is set to a fully ASCII path, Git Bash finds the home directory, but it still mangles the user name in the displayed messages.

5. The first time I run Git GUI, when I try to stage and commit a file, there is an error that says that there are invalid utf-8 characters in the commit message.
   The workaround for this consists in opening the Edit->Options dialog and entering a valid user name and an email address in the corresponding edit boxes.
   It seems that Git is composing an extended message based on my message plus the user name and email. Because the fields are empty, it seems to try to generate default values out of the Windows user name, but it probably retrieves that as an ISO-8859-1 string on my system, and then another part of the code expects that to be valid utf-8, but it isn’t.

6. If the user name and email fields are left empty, I’ve also come across the error shown in the image “error2.jpg” above when trying to modify some options in the Edit->Options dialog. However, this error doesn’t always happen, and I’m not sure about the exact steps that lead to it.

7. After I’ve set the HOME variable and the user name and email address, I can work without any problems, except for the next one.

8. Non-ASCII paths and file names can be staged and committed if they are made up of characters in the local Windows encoding (I think that’s ISO-8859-1 for Spanish, English and most Western European Windows systems).
   So, I’ve been able to stage and commit a file with the name “cañón.txt“.
   However, if the path contains Unicode characters impossible to represent in the local Windows encoding, like “C:\My tests\test五.txt“, such files appear mangled in the Git GUI window, and give a “no such file or directory” error when I attempt to stage them.