Junio C Hamano <gits...@pobox.com> writes: > Duy Nguyen <pclo...@gmail.com> writes: > >> This may or may not fall into the "mix different hash functions" >> category. In pack files version 4, trees are encoded to point to other >> trees or blobs by a (pack, offset) tuple. It would be great if the new >> object_id could support carrying this kind of object id around because >> it could help reduce object lookup cost a lot. (pack, offset) can be >> converted back to SHA-1 so no info is lost and hashcmp() can compare >> (pack, tuple) against an SHA-1 just fine. > > You mean "if it came in <pack, offset> format, convert it down to > <sha1> until the last second that it is needed (e.g. need to put > that in a tree object in order to compute the object name of the > containing tree object)"?
Sorry, obviously I meant "do not convert until the last second". > To me, <pack, offset> information smells to belong more to a "struct > object" (or its subclass) as an optional annotation---when a caller > is asked to parse_object(), you would bypass the sha1_read_file() > that goes and looks the object name up from the list of pack .idx > and instead go there straight using that annotation. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
