On Fri, Jan 25, 2013 at 10:58 AM, Junio C Hamano <gits...@pobox.com> wrote:
> Duy Nguyen <pclo...@gmail.com> writes:
>> On Fri, Jan 25, 2013 at 12:45 AM, Junio C Hamano <gits...@pobox.com> wrote:
>>>> How about this way instead: we keep track of where objects come from
>>>> so we can verify object source when we create or update something
>>>> that contains SHA-1.
>>> The overall approach taken by this series may be worth considering, but
>>> I do not think the check implemented here is correct.
>>> An object may be found in an alternate odb but we may also have our
>>> own copy of the same object. You need to prove that a suspicious
>>> object is visible to us *ONLY* through add_submodule_odb().
>> The way alt odbs are linked (new odbs area always at the end), if we
>> have the same copy, their copy will never be read (we check out alt
>> odbs from head to tail). So those duplicate suspicious objects are
>> actually invisible to us.
> The way I read find_pack_entry() is that our heuristics to start
> our search by looking at the pack in which we found an object the
> last time will invalidate your assumption above. Am I mistaken?
No, you are right. Loose objects are always searched from the start of
alt odb list. Packs are searched till the end then back to head again.
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