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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html