On 12/14/2011 03:33 AM, Jeff King wrote: > On Tue, Dec 13, 2011 at 04:19:19PM -0800, Junio C Hamano wrote: >> Actually, I do not think it even needs to be the "extra *REF* API". The >> only thing that matters is that these commits are considered to be extra >> anchor point in the history, in addition to the usual rule of considering >> that everything reachable from our refs is complete. The data structure to >> hold them does not even have to be a "struct ref". Just an array of object >> names (or "struct object *") should suffice. > > Since my cff38a5 (receive-pack: eliminate duplicate .have refs, > 2011-05-19), receive-pack simply has a packed array of binary sha1s (in > a "struct sha1_array" object). That might be the simplest thing. It was pretty easy to eliminate the use of extra_refs from receive-pack. I'll submit the patches as soon as I can. The patches will be based off of patch 16/51 of the ref-api-D series, since Junio indicated that he wants to queue up those commits (let me know if you have a different preference). 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? Moving the pack_refs() function to refs.c was on the agenda anyway, so it should be possible to sort this out at the same time. 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