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
Attachment:
signature.asc
Description: This is a digitally signed message part.
