Peter Krefting wrote:
In the other project I worked on we ended up wrapping all file-related calls
in our own porting interface, and then let each platform we compiled for
implement their own methods for handling Unicode paths. For Windows it's
trivial since all APIs are Unicode. For Unix-like OSes it's tricky as you
have to take the locale settings into account, but fortunately the world is
slowly moving towards UTF-8 locales, which eases the pain a bit.
Have you thought about all the consequences this would have for the
*nix people here? [*]
Even if you pretend that Git did always enforce UTF-8 paths in its
trees, so that there's no backward compatibility to be cared for,
you're still in a world of hurt when trying to check out such paths
under a locale (or whatever setting might control this new encoding
logic) that does not support the whole range of UTF-8.
Like, say, the C locale.
Next you get to see to it that the users can spell all filenames even
if their locale doesn't let them, since they'll want to do things like
'git show $rev:$file' with them.
With backwards compatibility it's even worse as you're suddenly
imposing extra restrictions on what a valid filename in the repository
must look like.
[*] I'm _extremely_ tempted to write "people using non-broken OSes",
but let's pretend to be neutral for a second.
--
Thomas Rast
trast@{inf,student}.ethz.ch