Re: Re-casing directories on case-insensitive systems

[Kevin Ballard <kevin@xxxxxx>]

Speaking of normalizing composed sequences, could that be the cause  
for the following?

kevin@KBALLARD:~/Dev/git> ls
kevin@KBALLARD:~/Dev/git> ls -a
./          ../         .git/       .gitignore
kevin@KBALLARD:~/Dev/git> git reset --hard
HEAD is now at 58beb2c... Trim leading / off of paths in git-svn  
prop_walk
kevin@KBALLARD:~/Dev/git> git st
# On branch master
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#	gitweb/test/Märchen
nothing added to commit but untracked files present (use "git add" to  
track)

Some further exploration seems to support my cause:

kevin@KBALLARD:~/Dev/git> git ls-files gitweb/test
"gitweb/test/M\303\244rchen"
gitweb/test/file with spaces
gitweb/test/file+plus+sign
kevin@KBALLARD:~/Dev/git/gitweb/test> ls Märchen | xxd
0000000: 4d61 cc88 7263 6865 6e0a                 Ma..rchen.

As you can see, git has the file tracked using M\303\244rchen, where  
\303\244 (or 0xC3A4, or U+00E4) is Latin Small Letter A With  
Diaeresis, but the filesystem reports it as "Ma\xCC\x88rchen" where  
0xCC88 (or U+0308) is Combining Diaeresis.

In other words, the git repository itself exhibits a problem under OS  
X. I'm not sure if I didn't notice this untracked file before, or if  
the filesystem (or the index) actually used the other form previously,  
but regardless there's a problem that I believe would be present even  
if I was using Case-Sensitive HFS+.

-Kevin Ballard

On Jan 11, 2008, at 6:26 PM, Robin Rosenberg wrote:

> Could we just have a lookup table index extension for identifying the
> duplicates (when checking is enabled using core configuration option  
> #3324)?
> That table would keep a mapping from a normalized form (maybe include
> canonical encoding while we're at it) to the actual octet  
> sequence(s) used.

--
Kevin Ballard
http://kevin.sb.org
kevin@xxxxxx
http://www.tildesoft.com

<<attachment: smime.p7s>>