All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Bryan Turner <bturner@atlassian.com>
Cc: Git Users <git@vger.kernel.org>
Subject: Re: HEAD and namespaces
Date: Tue, 21 May 2019 17:46:30 -0400	[thread overview]
Message-ID: <20190521214630.GD14807@sigill.intra.peff.net> (raw)
In-Reply-To: <CAGyf7-Ew8rS8n67Few9+dT6VXy9rQbaYLswuZkQ3-4j_T_d=qg@mail.gmail.com>

On Mon, May 20, 2019 at 07:59:03PM -0700, Bryan Turner wrote:

> When using GIT_NAMESPACE, it appears the "symref" added to the
> capabilities advertisement doesn't get the namespace stripped. The
> namespace is stripped for the advertised refs, including "HEAD", but
> not on the "symref".
> 
> Lafiel:test bturner$ GIT_NAMESPACE=foo GIT_TRACE_PACKET=1 git ls-remote origin
> 19:51:54.012696 pkt-line.c:80           packet:          git<
> b9acca03606d4c674be8b7e79cd788cedbec957c HEAD\0multi_ack thin-pack
> side-band side-band-64k ofs-delta shallow deepen-since deepen-not
> deepen-relative no-progress include-tag multi_ack_detailed
> symref=refs/namespaces/foo/HEAD:refs/namespaces/foo/refs/heads/master

Yeah, that seems totally broken. It's neat that we find HEAD inside the
namespace. But I think there are two bugs here:

  1. We must call it "HEAD" and not the nonsense
     refs/namespaces/foo/HEAD

  2. We need to similarly remove the namespace from its contents. I
     suppose it's possible that somebody stores the already-truncated
     name in the symref, but as you noted then such a symref would be
     totally broken from the perspective of the non-namespaced repo.

> I don't know whether the client somehow does some stripping on the
> "symref" to decide that HEAD should be
> "refs/namespaces/foo/refs/heads/master", but I'd assume not.

I don't think it can. It has no idea that namespaces are in play at all
(and the point of the feature is for it to be invisible to the client).

> Is this a bug? An oversight? An intentional decision? How is HEAD
> supposed to work when using GIT_NAMESPACE? Perhaps the expectation is
> that namespaces won't have their own HEADs? I'd say perhaps it's that
> even in the namespace the target ref shouldn't be namespaced, but that
> doesn't seem like it could possibly be correct since the namespace
> could contain refs that don't exist outside it, so Git would see the
> symbolic ref as broken.

I think it should be doing:

diff --git a/upload-pack.c b/upload-pack.c
index 24298913c0..4d2129e7fc 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -1037,8 +1037,8 @@ static int find_symref(const char *refname, const struct object_id *oid,
 	symref_target = resolve_ref_unsafe(refname, 0, NULL, &flag);
 	if (!symref_target || (flag & REF_ISSYMREF) == 0)
 		die("'%s' is a symref but it is not?", refname);
-	item = string_list_append(cb_data, refname);
-	item->util = xstrdup(symref_target);
+	item = string_list_append(cb_data, strip_namespace(refname));
+	item->util = xstrdup(strip_namespace(symref_target));
 	return 0;
 }
 

and this case has just been broken since 7171d8c15f (upload-pack: send
symbolic ref information as capability, 2013-09-17). It mostly works
because of fallback to the old guessing behavior, so nobody really
noticed. (I also suspect namespaces are not widely used at all, but I
could be wrong).

-Peff

  reply	other threads:[~2019-05-21 21:46 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-21  2:59 HEAD and namespaces Bryan Turner
2019-05-21 21:46 ` Jeff King [this message]
2019-05-22  4:31   ` [PATCH] upload-pack: strip namespace from symref data Jeff King
2019-05-22 10:33     ` Ævar Arnfjörð Bjarmason
2019-05-23  6:11       ` [PATCH v2] " Jeff King
2019-05-28 17:01         ` Junio C Hamano

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=20190521214630.GD14807@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=bturner@atlassian.com \
    --cc=git@vger.kernel.org \
    /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.