Re: git on MacOSX and files with decomposed utf-8 file names
- From
Johannes Schindelin <johannes.schindelin@gmx.de>
- Date
- Jan 17, 2008, 11:10 UTC
- Message-ID
- <alpine.LSU.1.00.0801171106510.17650@racer.site>
- In-Reply-To
- <32DB7E53-1062-4F7C-A42D-6EC5945A70A3@wincent.com>
Hi,
[Jay, don't cull Cc: lists on vger.kernel.org. I consider it rude.]
On Thu, 17 Jan 2008, Wincent Colaiuta wrote:
Show 12 quoted lines
> El 17/1/2008, a las 6:15, Junio C Hamano escribió: > > > "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?
Yes, and I think that a lot of time would have more wisely spent on reading that, and trying to implement it, than writing a number of long mails, repeating the _same_ (refuted) points over and over again.
Show 8 quoted lines
> > 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.
Agree.
Show 9 quoted lines
> 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.
Anything else but failure would be Not What You Want. You might want a special mode where you use a _different_ name on-disk (something like the infamous short names on FAT), but that _must_ be turned off by default: think of Martin's HEAD example. Sometimes, it's just not possible to check such a tree out on a less-than-nice system.
Ciao, Dscho