Re: [PATCH v2 28/51] refs.c: rename ref_array -> ref_dir
- From
Michael Haggerty <mhagger@alum.mit.edu>
- Date
- Jan 17, 2012, 15:07 UTC
- 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:
Show 20 quoted lines
> 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/