On Thu, Apr 04, 2013 at 07:35:16PM -0700, Josh Triplett wrote:

> > Including the HEAD ref in the advertisement from /info/refs ends up
> > duplicating it, since the dumb client unconditionally fetches the file
> > /HEAD to use as the that ref. I think the right thing to do is
> > generate the correct /HEAD using head_ref_namespaced(), rather than
> > returning the bare file $GIT_DIR/HEAD, but I'm not 100% sure how HEAD
> > and namespaces interact, since I haven't been able to produce a repo
> > with a different HEAD in a namespace. Can you verify this approach?
> Semantically, every namespace should act like a completely independent
> repository, which includes having its own independent HEAD.  A namespace
> should *not* see the HEAD of the entire repository, only its own
> namespaced HEAD.

Yeah, that makes sense. I think we'd want something like the (totally
untested) patch below. And the tests I provided for t5551 should be
amended to set up a HEAD within the namespace, should make the resulting
clone non-bare, and should confirm that we check out the correct HEAD.

diff --git a/http-backend.c b/http-backend.c
index 8144f3a..84ba7f9 100644
--- a/http-backend.c
+++ b/http-backend.c
@@ -376,6 +376,14 @@ static int show_text_ref(const char *name, const unsigned 
char *sha1,
        return 0;
+static void get_head(char *arg)
+       struct strbuf buf = STRBUF_INIT;
+       head_ref_namespaced(show_text_ref, &buf);
+       send_strbuf("text/plain", &buf);
+       strbuf_release(&buf);
 static void get_info_refs(char *arg)
        const char *service_name = get_parameter("service");
@@ -520,7 +528,7 @@ static struct service_cmd {
        const char *pattern;
        void (*imp)(char *);
 } services[] = {
-       {"GET", "/HEAD$", get_text_file},
+       {"GET", "/HEAD$", get_head },
        {"GET", "/info/refs$", get_info_refs},
        {"GET", "/objects/info/alternates$", get_text_file},
        {"GET", "/objects/info/http-alternates$", get_text_file},
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to