On Thu, Dec 15, 2011 at 09:19:08AM +0100, Michael Haggerty wrote:
> 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
--
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