Re: git on MacOSX and files with decomposed utf-8 file names

torsdagen den 17 januari 2008 skrev Kevin Ballard:

On Jan 17, 2008, at 10:57 AM, Johannes Schindelin wrote:

quoted

On Thu, 17 Jan 2008, Kevin Ballard wrote:

quoted

On Jan 17, 2008, at 5:22 AM, Wincent Colaiuta wrote:

quoted

While it's a nice workaround, it really is just that (a workaround)
because performance will be suboptimal in a repository running on a
disk image (and many of switched to Git because of its speed).

Not only is it suboptimal, it's also not acceptable, plain and  
simple.

If it's not acceptable, do something about it (and I don't mean  
writing 50
emails). If you don't want to do something about it, I have to  
assume that
you accept it as-is.

I never said I don't want to do anything about it. However, I do  
believe that it will take a significant investment of time and energy  
to learn all the gooey details of how git handles filenames and how  
the index works and all that jazz, which is knowledge that other  
people already have. I believe that, for me to solve this problem  
independently, it may require so much time that it never gets done  
(after all, I am fairly busy). However, if other people who already  
have this knowledge are willing to help, that would make this task far  
easier, especially given that if nobody else even acknowledges that  
this is a problem I don't have much hope of getting a patch accepted.

So again, I'm certainly going to try, but working by myself it simply  
may never get done.

(This is only for those that think the problem should be solved somehow. The
rest can move on - nothing to see here)

You may look at http://rosenberg.homelinux.net/cgi-bin/gitweb/gitweb.cgi?p=GIT.git;a=log;h=i18n
for inspiration. It's pretty obsolete by now and only a "proof of concept", i.e.
it can be done, not that it necessarily should be done exactly this way.

Basically it intercepts the user's access to git, i.e. certain commands
and how files are named (since those names represent a user interface). Then
it assumes the internal encoding is UTF-8 (or garbage) converting to and
from the user's local encoding. The heuristics is based on the assumption that
a string (even random onesthat looks like UTF-8, with a very high probablity
actually is UTF-8 encoded.

The test cases might be usable almost as is.

-- robin