Re: [PATCH 4/4] server info: Add HEAD to info/refs

[Junio C Hamano <junkio@cox.net>]

Petr Baudis <pasky@suse.cz> writes:

> For some reason, HEAD was not listed in info/refs until now, which means
> that git-ls-remote does not return it for dumb transports while the native
> transports show it. It would be nice to have it because of git-mirror and
> possibly other nifty stuff.

Hmmm.  I know why you want to do this, but honestly speaking,
this is going somewhat backwards.  Maybe one step back, before
going two steps forward.

I always considered it was a bug that the native transport sends
SHA-1 of HEAD after dereferencing the symref, instead of saying
which branch it points at.  You would understand (or more
likely, "remember", as I suspect you have in the past looked at
what git-clone does and git-clone-pack used to do) what yuck
factor this introduced to git-clone.

The info/refs files is designed to mimick peek-remote output (I
know you looked at ls-remote implementation that has "case-esac"
that switches on transport, whose output is piped to the same
filtering loop), but HEAD SHA-1 is not needed in this file to
support dumb transports, as we try to read HEAD symref by hand
when cloning over http.

Longer term, I would want to have a protocol extension to the
native stuff to additionally send the symref information, so
that git-clone does not have to guess.  At the same time, we
would probably want to update the output from git-peek-remote so
that it can say which branch HEAD points at more explicitly, and
in such way that does not break older clients too badly.  We
would need to update the file format of info/refs at the same
time if we update git-peek-remote.

How about proceeding along these lines?

 * We take this patch to add HEAD SHA-1 to info/refs;

 * We add --symref option to git-ls-remote; without the option,
   its last "while read sha1 path" loop filters out lines that
   begin with "->";

 * We add native protocol extension to let upload-pack to say
   what HEAD symref points at, in addition to the SHA-1 HEAD
   points at.  Update peek-remote to show this information like
   this:

	->refs/heads/master<TAB>HEAD<LF>
        0d5e6c97...<TAB>HEAD<LF>
	...

 * We also enhance update-server-info to generate similar ->
   information.

 * We update git-clone to use --symref when it calls
   git-ls-remote; if it can figure out which branch the remote
   HEAD points at (because the remote side has newer git), it
   uses that information to set the HEAD branch instead of
   guessing.

Hmm?