Hi, On Thu, 14 Dec 2006, Shawn O. Pearce wrote: > When comparing file contents during the second loop through a rename > detection attempt we can skip the expensive byte-by-byte comparsion if > both source and destination files have valid SHA1 values. This improves > performance by avoiding either an expensive open/mmap to read the > working tree copy, or an expensive inflate of a blob object. > > Unfortunately we still have to at least initialize the sizes of the > source and destination files even if the SHA1 values don't match. > Failing to initialize the sizes causes a number of test cases to fail > and start reporting different copy/rename behavior than was expected. It has a wrong feel to it when you say we have to check the sizes first. After all, we are heavily relying on the hashes being different, including the case when the sizes are different. So, the order of the checks should _not_ matter. I suspect that somewhere sha1_valid should be set to 0, but isn't. 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