Re: [PATCH 0/6] Introduce commit notes

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

Hi,

On Mon, 16 Jul 2007, Junio C Hamano wrote:

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

In which case it is not _that_ attractive any more, since you

- have to have a fallback anyway, and

- have a relatively complex thing.

Instead, I want to go with the hash map approach, if only to have a O(1) 
behaviour instead of O(log N).

Ciao,
Dscho