From: Jeff King <peff@peff.net>
To: git@vger.kernel.org
Cc: Kevin Sawicki <kevin@github.com>
Subject: [PATCH 0/4] exact ref-matching for fetch-pack
Date: Mon, 12 Dec 2011 19:39:25 -0500 [thread overview]
Message-ID: <20111213003925.GA28403@sigill.intra.peff.net> (raw)
I was passed a bug report of clone failing on a repo with an oddly named
ref in it: "refs/for/refs/heads/master". This is probably an error
somebody made while pushing and should simply be deleted. However, it's
curious that "clone" would fail on this, since it should be ignoring
everything outside the "refs/heads/*" refspec.
It turns out that during the fetch-pack phase, we accidentally ask for
the sha1 of "refs/for/refs/heads/master" instead of that of
"refs/heads/master". This can cause "clone" to fail, as we may not have
asked for the object pointed to by "refs/heads/master" at all. This
behavior is due to some questionable suffix-matching deep inside
fetch-pack. The code in question dates back to the beginning of git; I
think it simply hasn't triggered much because the refname you need to
have is so specific (you must be asking to fetch a ref "refs/X", have
"refs/Y/X" on the remote, and "Y" must come alphabetically before "X",
since we match refs in alphabetical order).
As I said, this is probably just a silly one-off error. But I could
imagine this happening legitimately. Here are two possible scenarios:
1. You are mirroring some meta-information about your refs in a
parallel namespace. E.g., "refs/descriptions/refs/heads/master"
contains information about "refs/heads/master".
2. One of the things we've discussed for future git is mirroring the
remote ref namespaces more literally. E.g., having something like
"refs/remotes/origin/refs/heads/master". That won't actually
trigger this bug because "heads" is alphabetically before
"remotes". But "tags", for example, is not.
This could possibly be considered a behavior regression for users of the
fetch-pack command line. See patches 2 and 3 for details.
[1/4]: drop "match" parameter from get_remote_heads
[2/4]: t5500: give fully-qualified refs to fetch-pack
[3/4]: fetch-pack: match refs exactly
[4/4]: connect.c: drop path_match function
-Peff
next reply other threads:[~2011-12-13 0:39 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-13 0:39 Jeff King [this message]
2011-12-13 0:41 ` [PATCH 1/4] drop "match" parameter from get_remote_heads Jeff King
2011-12-13 0:44 ` [PATCH 2/4] t5500: give fully-qualified refs to fetch-pack Jeff King
2011-12-13 0:48 ` [PATCH 3/4] fetch-pack: match refs exactly Jeff King
2011-12-13 0:54 ` Jeff King
2011-12-15 21:46 ` Junio C Hamano
2011-12-13 0:49 ` [PATCH 4/4] connect.c: drop path_match function Jeff King
2011-12-13 3:23 ` Michael Haggerty
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=20111213003925.GA28403@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=kevin@github.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).