On 12/14/2011 12:24 AM, Junio C Hamano wrote: > Michael Haggerty <mhagger@xxxxxxxxxxxx> 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@xxxxxxxxxxxx http://softwareswirl.blogspot.com/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html