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".
next prev parent 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.