Re: Git --reference bug(?)

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 19, 2011, 06:55 UTC
Message-ID: <7v4nz5eah5.fsf@alter.siamese.dyndns.org>
In-Reply-To: <7v8vohebhx.fsf@alter.siamese.dyndns.org>

Junio C Hamano <gitster@pobox.com> writes:

Show 9 quoted lines

> Junio C Hamano <gitster@pobox.com> writes:
>
> In addition, you must be careful about what is added with add_extra_ref();
> they are often not refs but are placeholders for Git to know that the
> history leading to it is complete, even though they do not exist as
> refs. The values of real refs that exist in your alternate object store
> are treated this way, because you know you do not have to fetch (if you
> are initiating fetch-pack) or receive (if the other side is initiating
> send-pack) histories leading to them from the other side.

I think a quick and simple rule would be that add_extra_ref() is to give our history in the object database extra anchor points to avoid fetching or receiving pushes of unnecessary history into our object database, when we know our object database has certain histories that are not reachable from our own refs available. The names given to add_extra_ref() would not follow any normal refname rules (in fact, "refs/tags/v2.6.12-rc3^{}" peeled notation was designed not to collide with real refs, so was ".have" sent from receive-pack.c to send-pack.c even though the latter is not kept track of with the refs mechanism).

They do not have to be shown when resolve_ref() is called. They only need to appear in for_each_ref() so that revision walking machinery can use them when we need to compute the set-difference of commits between what we have and what the other side has.

Hope this clears things up a bit.