From: Michael Haggerty <mhagger@alum.mit.edu>
Date: Tue, 17 Jan 2012 15:07:05 GMT
Subject: Re: [PATCH v2 28/51] refs.c: rename ref_array -> ref_dir
Message-ID: <4F158E99.2020906@alum.mit.edu>
In-Reply-To: <7vzkewt5qu.fsf@alter.siamese.dyndns.org>

On 12/14/2011 12:24 AM, Junio C Hamano wrote:
> Michael Haggerty <mhagger@alum.mit.edu> writes:
>> ...  But there are so many calls to the
>> for_each_ref*() family of functions that I wasn't able to determine
>> exactly which should allow for extra refs and which shouldn't.
> 
> Only the ones that follow add_extra_ref() in the control flow.
> 
> builtin/clone.c adds them in setup_reference() to deal with --reference.
> The objects known to be complete in these repositories we borrow from
> need to be marked complete on our end (i.e. clone does not have to fetch)
> and transport_fetch_refs() that eventually goes to fetch_refs_via_pack()
> that calls fetch_pack() uses this information. All three for_each_ref()
> calls in builtin/fetch-pack.c are about "what are the objects that we know
> are complete?" and needs to pay attention to extra refs.
> 
> Having said that, I have a slight suspicion that you might be able to
> eliminate this one in clone.  setup_reference() adds the reference
> repository to the $GIT_DIR/objects/info/alternates, and the fetch logic
> already knows to account for the refs in alternate repositories via
> insert_alternate_refs() callchain.

If I comment out the call from add_one_reference() to add_extra_ref()
then I get a single failure, in t5700:

not ok - 8 fetched no objects
#	! grep "^want" "$U"

So your suspicion does not seem to be borne out (at least not in the
naivest form).

Still studying...
Michael

-- 
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/