On Thu, Apr 04, 2013 at 06:22:08PM -0700, John Koleszar wrote:
> On Thu, Apr 4, 2013 at 10:25 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> > John Koleszar <jkoleszar@xxxxxxxxxx> writes:
> >
> >> @@ -402,7 +404,8 @@ static void get_info_refs(char *arg)
> >>
> >> } else {
> >> select_getanyfile();
> >> - for_each_ref(show_text_ref, &buf);
> >> + head_ref_namespaced(show_text_ref, &buf);
> >> + for_each_namespaced_ref(show_text_ref, &buf);
> >> send_strbuf("text/plain", &buf);
> >> }
> >
> > Whether we are namespaced or not, we used to do for_each_ref() here,
> > not advertising the HEAD (outside refs/ hierarchy), but we now do,
> > and as the first element in the output.
> >
> > Am I reading the patch correctly?
> >
> > Is that an unrelated but useful bugfix even for people who do not
> > use server namespaces?
> >
>
> Actually, I think this line may be buggy. Hold off submitting if you
> haven't already.
>
> 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.
Namespaces exist so that you can make a pile of repos share the same
object store while acting as independent repositories. As long as you
never expose the un-namespaced repository, a client should not be able
to tell whether you use namespaces.
- Josh Triplett
--
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