On Tue, Apr 29, 2014 at 11:49:30AM -0700, Junio C Hamano wrote:

> Jeff King <p...@peff.net> writes:
> > I don't think we have a "str_utf8_cmp" that ignores normalizations (or
> > maybe strcoll will do this?). But in theory we could use it everywhere
> > we use strcasecmp for ignore_case. And then we would not need to have
> > our readdir wrapper, maybe? I admit I haven't thought that much about
> > _either_ approach. But aside from some bugs in the hash system, I do not
> > recall seeing any design problems in the ignorecase code.
> Our diffs and merges depend on walking two (or more) sorted lists,
> and that sort order is baked in the tree objects when they are
> created.  Using "normalized comparison" only when comparing the
> earliest elements picked from these sorted lists would not give you
> the correct comparison or merge results, would it?

Right, but we do not do normalized comparisons on that side. Not for
precompose, and not for ignorecase. The entry in the index _is_
case-sensitive[1], and we compare it as such to the tree side.

It is only when comparing the filesystem side to the index that we need
to care about such normalizations. And there we have the name-hash code
to handle ignorecase, but nothing to handle precompose.


[1] This works because you typically get the case-sensitive entry via
    `git read-tree`, and then further update it from the filesystem. If
    you were to add a new entry "makefile", and somebody else added
    "Makefile", they would conflict.

    When you do "git add makefile" and "Makefile" _does_ exist, I am not
    sure, though, if it is git who handles making sure we find the
    correct entry, or if it is simply the fact that case insensitive
    filesystems are typically case-preserving (so you generally ask for
    "Makefile" anyway). If it is the latter, then that is a problem for
    precompose. HFS's NFD normalization is non-preserving.
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

Reply via email to