Hi, On Mon, 16 Jul 2007, Junio C Hamano wrote: > Johannes Schindelin <Johannes.Schindelin@xxxxxx> 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 - 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
