Linus Torvalds wrote: [snip] > So what you can do (and I'd argue that we do) is to have a hash that can > handle almost arbitrary input, but then never corrupt the filename, and > always compare exactly by default. In general, there may be a large number of comparison function options that git will eventually support, and they will likely not all form a single chain of increasing "strictness". Given that the hash values aren't even being stored on disk (and if they were, a simple approach of also storing an identifier for the hash function to know whether they stored values are still valid could be used), having a chain of increasingly "strict" comparison functions and using a hash function that corresponds to the least strict one is useful for exactly one reason: giving (possibly several different levels of) non-fatal warnings for various types of duplicates. But since multiple hash functions will be needed anyway to support different notions of case-insensitivity, if the warning is not enabled, there is no reason to use a case-insensitive hash function with a byte-exact comparison. -- Jeremy Maitin-Shepard - 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
