Re: [PATCH 0/6] Introduce commit notes

[Junio C Hamano <gitster@pobox.com>]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

>> Hmph, you are right.  In this sequence:
>> 
>> 	hex = sha1_to_hex(commit->object.sha1);
>> 	snprintf(name, sizeof(name), "%s:%.*s/%.*s",
>> 			notes_ref_name, 2, hex, 38, hex + 2);
>> 	if (get_sha1(name, sha1))
>> 		return;
>> 
>> Instead, we could read the tree object by hand in the commit that is 
>> referenced by notes_ref_name, which has uniform two letter names for 
>> subtrees which can be binary searched, open the tree for that entry, 
>> again by hand, and do another binary search because that tree has 
>> uniform 38-letter names.  That certainly could be done.
>> 
>> Sounds like a "fun" project for some definition of the word.
>
> I disagree.  One disadvantage to using tree objects is that it is much 
> easier to have pilot errors.  You could even make a new working tree 
> checking out refs/notes/commits and change/add/remove files.

I suspect you read me wrong.  I was saying that it is possible
to use a specialized tree object parser in place of get_sha1()
only in the above code to read the tree objects that represents
a 'note'.  You obviously would want to do a sanity check such
as:

 - The size of the tree object your customized tree parser is
   fed is multiple of expected entry size (mode word + 20 SHA1 +
   2 + NUL for fan-out, replace 2 with 38 for lower level);

 - mode word for the entry is sane (an entry in the fan-out tree
   would point at a tree object, an entry in lower level would
   point at a blob);

 - The name part (2 or 38) are lowercase hexadecimal strings;