Re: git on MacOSX and files with decomposed utf-8 file names
- From
Wincent Colaiuta <win@wincent.com>
- Date
- Jan 17, 2008, 10:28 UTC
- Message-ID
- <32DB7E53-1062-4F7C-A42D-6EC5945A70A3@wincent.com>
- In-Reply-To
- <7vejchkp6o.fsf@gitster.siamese.dyndns.org>
El 17/1/2008, a las 6:15, Junio C Hamano escribió:
Show 19 quoted lines
> "Jay Soffian" <jaysoffian+git@gmail.com> writes: > >> So here's what I can see as being useful additions to git: >> ... >> Thoughts (besides "patches welcomed")? > > I think we already discussed a plan to store normalization > mapping in the index extension section and use it to avoid > getting confused by readdir(3) that lies to us. Is there any > more thing that need to be discussed? > > I would presume that we would still add _new_ paths using the > pathname we receive from the user (there is no need for us to be > similarly insane as broken "normalizing" filesystems), but when > deciding if a path is new or we already have it in the index > would be done by seeing if an entry already exists in the index > whose "normalized" form is the same as the "normalized" form of > the given path --- that way we would not add two paths to the > index that would "normalize" to the same string.
And what do we do when asked to check out a tree which has two different files in it whose normalized forms are the same (ie. a clone of a repo created on a non-HFS+ filesystem)?
We either have to fail catastrophically, preventing the user from working with that tree on HFS+, or arbitrarily pick one of the files as the "winner" which gets written out into the work tree. None of the options is particularly attractive, although luckily this exact situation is unlikely to come up in practice.
Cheers, Wincent