Re: [PATCH 1/7] sha1_file: keep track of where an SHA-1 object comes from
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Jan 25, 2013, 03:58 UTC
- Message-ID
- <7v4ni59ano.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <CACsJy8Ag6v7wUnupRwGid26AUzgZ=WbdA5F-MpjUv5ktaj5Asg@mail.gmail.com>
Duy Nguyen <pclouds@gmail.com> writes:
Show 16 quoted lines
> On Fri, Jan 25, 2013 at 12:45 AM, Junio C Hamano <gitster@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?