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
> 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.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html