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