From: Junio C Hamano <gitster@pobox.com>
To: Michael Haggerty <mhagger@alum.mit.edu>
Cc: Andrea Gelmini <andrea.gelmini@gmail.com>, git@vger.kernel.org
Subject: Re: Git --reference bug(?)
Date: Tue, 18 Oct 2011 23:55:50 -0700 [thread overview]
Message-ID: <7v4nz5eah5.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <7v8vohebhx.fsf@alter.siamese.dyndns.org> (Junio C. Hamano's message of "Tue, 18 Oct 2011 23:33:46 -0700")
Junio C Hamano <gitster@pobox.com> writes:
> 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.
prev parent reply other threads:[~2011-10-19 6:55 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-18 22:04 Git --reference bug(?) Andrea Gelmini
2011-10-19 5:01 ` Michael Haggerty
2011-10-19 6:21 ` Junio C Hamano
2011-10-19 6:25 ` Junio C Hamano
2011-10-19 6:33 ` Junio C Hamano
2011-10-19 6:55 ` Junio C Hamano [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7v4nz5eah5.fsf@alter.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=andrea.gelmini@gmail.com \
--cc=git@vger.kernel.org \
--cc=mhagger@alum.mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).