On Mon, Apr 28, 2014 at 10:49:30PM +0200, Torsten Bögershausen wrote: > OK, thanks for the description. > In theory we can make Git "composition ignoring" by changing > index_file_exists() in name-hash.c. > (Both names must be precomposed first and compared then) Yeah, we could perhaps get away without storing the extra precomposed form if we just stored the entries under their precomposed hash, and then taught same_name to use a slower precompose-aware comparison. But I also see that we do binary searches in index_name_pos (called by index_name_is_other). I don't know if we'd have to deal with this problem there, too. > I don't know how much people are using Git before 1.7.12 (the > first version supporting precomposed unicode). > > Could we simply ask them to upgrade ? I'm not sure what you mean here. Upgrading won't help, because the values are baked into existing history created with the old versions forever. Any time I "git checkout v1.0" on the broken project, a modern git will complain about the ghost untracked file. > The next problem is that people need to agree if the repo should store > names in pre- or decomposed form. > (My voice is for precomposed) > Unfortunatly the core.precomposeunicode is repo-local, so everybody > needs to "agree globally" and "configure locally". Yeah, that was sort of my "point 1" from the patch. I'm a bit worried that it creates problems for people on other systems, though. Linux people do not need to care about precomposed/decomposed at all, and any attempt we make to automatically handle it is going to run afoul of non-utf8 encodings. Not to mention that it does not solve the "git checkout v1.0" problem above. > Side note: > I which we had this config variable travelling with the repo, like .gitattributes does > for text dealing with CRLF-LF. Yeah, I guess if we wanted to enforce it everywhere, you would have to use .gitattributes since we cannot safely turn on such a feature by default. > I don't know how many reports you have, reading all this it feels as if the effected users > could "normalize" their repos and run "git config core.precomposeunicode true", followed > by "git config --global core.precomposeunicode true". > Does that sound like a possible way forward ? I have just a handful of reports. Maybe 3-4? I didn't dig them all up today, as it would be a non-trivial effort. But I have no idea how good a sampling that is. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html