Re: [PATCH v2 28/51] refs.c: rename ref_array -> ref_dir
- From
Jeff King <peff@peff.net>
- Date
- Dec 15, 2011, 08:37 UTC
- Message-ID
- <20111215083732.GA5958@sigill.intra.peff.net>
- In-Reply-To
- <4EE9AD7C.2050605@alum.mit.edu>
On Thu, Dec 15, 2011 at 09:19:08AM +0100, Michael Haggerty wrote:
Show 6 quoted lines
> Now I'm looking at the uses of extra_refs in git-clone. One thing it > does is add some extra refs then write them to the packed-refs file. I > still have to dig into it, but this seems strange. If the refs are > being written to packed-refs, it seems like they must be real (not > extra) refs, or perhaps are just about to become real refs as part of > the clone. Or is something more egregious is going on?
I think what is happening is that the extra_refs system is doing double duty here. If you do:
git clone --reference $local $origin
then the code does something like:
1. Add all of the refs in $local are added to extra_refs, because we
want to advertise them during the pack fetch (see add_one_reference,
called through setup_reference at l. 626). 2. We then get the list of remote refs from $origin and store them in
mapped_refs (ll. 657-658). The fetch uses the extra refs from (1).3. We call clear_extra_refs to drop those temporary refs (l. 663).
4. We call write_remote_refs (l. 664), which adds all of the
mapped_refs from (2) to extra_refs, then calls pack_refs which will
pack all of the existing refs (of which there should be none, I
would think), including extras (i.e., all the stuff we just
cloned). Afterwards we clear_extra_refs again, though I think that is
probably unnecessary.Keeping the ".have" sha1s out of extra_refs would make this a lot clearer. Arguably it would also be better to have some way to just pass the set of mapped_refs to pack_refs, instead of shoving them in the global extra_refs and relying on pack_refs to find them there.
-Peff