Re: [REVISED PATCH 2/6] Introduce commit notes

> 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?