Hi, On Tue, 22 Jan 2008, Junio C Hamano wrote: > * We certainly do not necessarily want to store this in the > index right now. The hash algorithms would be improved from > the version you are almost ashamed of ;-). That sounds as if > I am retrating the other half, but not quite. > > * Once we have a mechanism to detect that the extension section > stores a precomputed hash that was done with a different > algorithm and ignore it (and recompute afresh when needed), > then we can afford to put a more elaborate hashing algorithm, > slightly loosening one of your "Guiding principles", and keep > the result in the generated index to be reused by the next > user. So that is why I am retracting only half of the > suggestion to save it in the extension section (which in turn > is a half of my suggestion). Both issues (and the config variable issue Linus raised) are easily helped with: store not only the hashmap in the extension, but also an identifier for the hash method used. Then you can improve on the hash function all you like, and add the config variable dependent choice of the hashing everybody seems to want all of a sudden, as long as you change the method identifier, too. Ciao, Dscho - 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
