Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> writes: > On Thu, 19 Jul 2007, Junio C Hamano wrote: >> > ... >> > But the real problem of this approach of course is that this is >> > not reliable and can get a false match. You can find your >> > beginning NUL in the SHA-1 part of one entry, and terminating >> > NUL later in the SHA-1 part of next entry, and you will never >> > notice. > > [ I didn't react to this in your first email, because I thought you were > talking about your "use the rules for the ASCII part", and thought you > talked about how *that* was not reliable and can get a false match). But > it seems that you were actually talking about the NUL character test ] > > Nope, wrong. > > Why? Because there must always be a NUL *between* different SHA1's. > There's *always* a NUL character that precedes a SHA1. So when you have > two NUL characters (with no other NUL's between them), you *know* that > they cannot be from two different SHA1's. If the first one was from an > earlier SHA1, then the second one is *guaranteed* to be the one that > happens *before* the next SHA1. > > See? Ok. As usual, you are more right than I am ;-). - 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
