From: Junio C Hamano <gitster@pobox.com>
Date: Thu, 12 Mar 2015 18:44:31 GMT
Subject: Re: [PATCH v2 01/10] Define a structure for object IDs.
Message-ID: <xmqqa8zi2gz4.fsf@gitster.dls.corp.google.com>
In-Reply-To: <xmqqwq2m2hwf.fsf@gitster.dls.corp.google.com>

Junio C Hamano <gitster@pobox.com> writes:

> Duy Nguyen <pclouds@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.