git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: mhagger@alum.mit.edu
Cc: git@vger.kernel.org, Jeff King <peff@peff.net>,
	cmn@elego.de, A Large Angry SCM <gitzilla@gmail.com>,
	Daniel Barkalow <barkalow@iabervon.org>,
	Sverre Rabbelier <srabbelier@gmail.com>
Subject: Re: [RFC 04/13] add_ref(): move the call of check_refname_format() to callers
Date: Wed, 19 Oct 2011 14:49:53 -0700	[thread overview]
Message-ID: <7vsjmobqim.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <1319057716-28094-5-git-send-email-mhagger@alum.mit.edu> (mhagger@alum.mit.edu's message of "Wed, 19 Oct 2011 22:55:07 +0200")

mhagger@alum.mit.edu writes:

> I'm still not clear on how extra_refs are used.  Are they generated
> from local refs or are they generated from remote refs?  If the
> latter, then it is probably irresponsible not to do *some* sanity
> checking in add_extra_ref() to prevent any chance of refnames like
> "../../../etc/passwd".

No, add_extra_ref() already tells us what their values are, these are
never used to actually read from filesystem. Their refname field has
almost no value other than for debugging and we probably shouldn't even
insist on uniqueness among extra refs or for that matter collision with
the real refs. As I mentioned in an earlier message, their only raison
d'être is to be found by for_each_ref() that feeds revision machinery with
up to which commits we know we have complete histories for. A sample call
chain looks like this:

 - cmd_clone()
  - setup_reference()
   - add_one_reference()
     - add_extra_ref()
       adds refs in other repositories we borrow from as "extra"
  - transport_fetch_refs()
   - fetch_refs_via_pack()
    - fetch_pack()
     - do_fetch_pack()
      - find_common()
       - for_each_ref(rev_list_insert_ref)

That way find_common() thinks histories leading to these extra refs are
already complete on our end (i.e. we have all the necessary objects), and
by subtracting that from what we are asking from the other end, we can
reduce the amount of history that needs to be transferred.

  reply	other threads:[~2011-10-19 21:50 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-19 20:55 [RFC 00/13] Checking full vs. partial refnames mhagger
2011-10-19 20:55 ` [RFC 01/13] check_refname_component(): iterate via index rather than via pointer mhagger
2011-10-19 20:55 ` [RFC 02/13] parse_refname_prefix(): new function mhagger
2011-10-19 20:55 ` [RFC 03/13] Teach check_refname_format() to check full refnames mhagger
2011-10-19 20:55 ` [RFC 04/13] add_ref(): move the call of check_refname_format() to callers mhagger
2011-10-19 21:49   ` Junio C Hamano [this message]
2011-10-19 21:59     ` Michael Haggerty
2011-10-19 20:55 ` [RFC 05/13] receive-pack::update(): use check_refname_format(..., REFNAME_FULL) mhagger
2011-10-19 20:55 ` [RFC 06/13] strbuf_check_branch_ref(): " mhagger
2011-10-19 20:55 ` [RFC 07/13] one_local_ref(): " mhagger
2011-10-19 20:55 ` [RFC 08/13] expand_namespace(): the refname is full, so use REFNAME_FULL option mhagger
2011-10-19 20:55 ` [RFC 09/13] new_branch(): verify that new branch name is a valid full refname mhagger
2011-10-19 21:52   ` Junio C Hamano
2011-10-19 20:55 ` [RFC 10/13] strbuf_check_tag_ref(): the refname is full, so use REFNAME_FULL option mhagger
2011-10-19 20:55 ` [RFC 11/13] replace_object(): " mhagger
2011-10-19 20:55 ` [RFC 12/13] resolve_ref: use check_refname_format(..., REFNAME_FULL) mhagger
2011-10-19 20:55 ` [RFC 13/13] filter_refs(): the refname is full, so use REFNAME_FULL option mhagger

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=7vsjmobqim.fsf@alter.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=barkalow@iabervon.org \
    --cc=cmn@elego.de \
    --cc=git@vger.kernel.org \
    --cc=gitzilla@gmail.com \
    --cc=mhagger@alum.mit.edu \
    --cc=peff@peff.net \
    --cc=srabbelier@gmail.com \
    /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).