On Thu, Apr 04, 2013 at 10:34:49PM -0700, Junio C Hamano wrote:

> > +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);
> > +}
> You identified the right place to patch, but I think we need a bit
> more than this.
> The show_text_ref() function gives "SHA-1 <TAB> refname". It is
> likely that the dumb client will ignore the trailing part of that
> output, but let's avoid a hack that we would not want see other
> implementations imitate.

Oh, right. I was thinking too much about normal clients which see HEAD
in the ref advertisement; of course the dumb client is expecting to see
the actual HEAD file.

> One advantage dumb clients has over smart ones is that they can read
> HEAD that is a textual symref from a dumb server and learn which
> branch is the default one (remote.c::guess_remote_head()) without
> guessing.  I think this function should:
>  - Turn "HEAD" into a namespaced equivalent;
>  - Run resolve_ref() on the result of the above;
>  - Is it a symbolic ref?
>    . If it is, then format "ref: <target>\n" into a strbuf and send
>      it (make sure <target> is without the namespace prefix);
>    . Otherwise, HEAD is detached. Prepare "%s\n" % sha1_to_hex(sha1),
>      and send it.

Yes, that sounds right; it is basically just reconstructing a HEAD
file. What do the HEADs inside namespaces look like? Do they refer to
full global refs, or do they refer to refs within the namespace?

If the latter, we could just send the HEAD file directly. But I suspect
it is the former, so that they can function when non-namespaced commands
are used.

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