git-cola failed to launch when source tree is under non-ASCII directory under Windows

[Vdragon]

Reproduce steps

1. find a Windows command-line prompt
2. make; make prefix=軟體\git-cola install
3. cd 軟體\git-cola
4. python bin/git-cola

Traceback

Traceback (most recent call last):
  File "bin/git-cola", line 365, in <module>
    sys.exit(main())
  File "bin/git-cola", line 77, in main
    return args.func(args)
  File "bin/git-cola", line 219, in cmd_cola
    context = application_init(args)
  File "share\git-cola\lib\cola\app.py", line 258, in app
lication_init
    process_args(args)
  File "share\git-cola\lib\cola\app.py", line 232, in pro
cess_args
    'Consider supplying -r <path>.\n' % repo)
UnicodeEncodeError: 'cp950' codec can't encode character u'\xb3' in position 50: illegal multibyte sequence

Reporter's environment

• Windows 8.1 x86 64-bit(version 6.3 (build 9600))
• Python 2.7.7(64-bit x86) is in the %PATH%
• Locale
  • Codepage 950(Big5)
• git-cola
  • commit 81774fa

[davvid]

Well, I was able to fix that error message based on the traceback, but I can't reproduce this one because I'm probably using utf-8 filesystem paths.

Do you know whether the filesystem paths are using a non-utf-8 encoding? I know Git itself has issues with non-utf-8 filesystem paths, and we do a lot of encoding/decoding of strings which forces us to require utf-8 for the filesystem itself.

We would need a way to get the filesystem encoding, it seems. I can try using os.getcwdu() instead of os.getcwd() as well, since that might help as well. Yep, unicode is hard ;-)

[davvid]

I added another tweak so that we avoid a decode()/encode() round trip when getting the repository path. Would you mind testing this again? There's a hope that this may have fixed this issue.

Unfortunately we may need to require utf-8 filesystem paths, but we'll see if this helps since it may make a difference. (crossing my fingers ;-))

[Vdragon]

@davvid

Do you know whether the filesystem paths are using a non-utf-8 encoding?
We would need a way to get the filesystem encoding, it seems.

The filesystem itself(NTFS) probably using UTF-16 however I suspect that os.getcwdu() should be fine dealing with this without caring which encoding are used under the hood.

I added another tweak so that we avoid a decode()/encode() round trip when getting the repository path.

I still get the exact same traceback using version c2dd395
I managed to make it launch by version 749859b but I really don't know why.