All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: Matt Burke <spraints@gmail.com>, git@vger.kernel.org
Subject: Re: Bug report: stash in upstream caused remote fetch to fail
Date: Mon, 06 Jan 2014 15:22:20 -0800	[thread overview]
Message-ID: <xmqq4n5ghf0z.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <20140106230348.GA7811@sigill.intra.peff.net> (Jeff King's message of "Mon, 6 Jan 2014 18:03:48 -0500")

Jeff King <peff@peff.net> writes:

> Then we ask fetch_refs_via_pack to get the actual objects for us. And
> it checks our refs again, with this call chain:
>
>   do_fetch
>     fetch_refs
>       transport_fetch_refs
>         fetch_refs_via_pack
>           fetch_pack
>             do_fetch_pack
>               everything_local
>                 filter_refs
>                   check_refname_format
>
> Here, the code looks like this:
>
>   if (!memcmp(ref->name, "refs/", 5) &&
>       check_refname_format(ref->name + 5, 0))
>     ; /* trash */

I think this should feed ref->name, not ref->name + 5; an obvious
alternative would be to use REFNAME_ALLOW_ONELEVEL; you are also
right that && is probably a misspelt ||; this is about protecting
ourselves from creating garbage in our ref namespace, so accepting
anything outside refs/ makes little sense.

> It's really not clear to me what the check in filter_refs was trying to
> do. It dates all the way back to 1baaae5 (Make maximal use of the remote
> refs, 2005-10-28), but there is not much explanation. I haven't dug into
> the list around that time to see if there's any discussion.

I think the "funny refs" the log message talks about is about
filtering "we know we can reach these objects via our alternates,
but these are not refs we actually have".

  reply	other threads:[~2014-01-06 23:22 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-03 21:12 Bug report: stash in upstream caused remote fetch to fail Matt Burke
2014-01-06 15:27 ` Jeff King
2014-01-06 16:16   ` Junio C Hamano
2014-01-06 19:36     ` Jeff King
2014-01-06 20:17       ` Junio C Hamano
2014-01-06 23:03         ` Jeff King
2014-01-06 23:22           ` Junio C Hamano [this message]
2014-01-07  3:19             ` Junio C Hamano
2014-01-15 10:46               ` Jeff King
2014-01-15 10:48                 ` Jeff King
  -- strict thread matches above, loose matches on Subject: below --
2012-02-01 16:59 Andrew Walrond
     [not found] ` <874nvap9hj.fsf@thomas.inf.ethz.ch>
2012-02-01 22:37   ` Andrew Walrond

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=xmqq4n5ghf0z.fsf@gitster.dls.corp.google.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=peff@peff.net \
    --cc=spraints@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.