Re: remote's HEAD not detected correctly

From: Jeff King <peff@peff.net>
Date: Feb 28, 2011, 21:42 UTC
Message-ID: <20110228214207.GA5854@sigill.intra.peff.net>
In-Reply-To: <AANLkTimqTa24QSWACFX9GErt-Tn+wLda1s_AvH7dzEpm@mail.gmail.com>

On Mon, Feb 28, 2011 at 01:01:08PM -0800, Shawn O. Pearce wrote:

Show 18 quoted lines

> On Mon, Feb 28, 2011 at 12:52, Jeffrey Middleton <jefromi@gmail.com> wrote:
> >
> > So somehow, the clone misses the fact that origin's HEAD is pu, not
> > master, and git remote is only partially aware of this. It looks like
> > this only happens when the two branches in question are pointing to
> > the same commit; perhaps git is trying to guess what HEAD is via the
> > SHA1? I know that ls-remote prints an SHA1, not a refname, for HEAD -
> > is it not actually possible to get that information through a general
> > transport protocol?
> 
> Right. The transport protocol doesn't expose the name that a symbolic
> reference points to, only its current value. Thus clients are forced
> to guess by looking for another reference whose current SHA-1 is the
> same. If there is more than one, its taking a best guess.
> 
> There have been a few attempts to expand the protocol and include the
> current symbolic reference target name, but thus far it hasn't gotten
> much beyond the idea stage.

It depends on the transport protocol. It actually works over dumb http, though I suspect that is not getting used much these days. I also implemented a quick-and-dirty patch for local repositories here:

  http://article.gmane.org/gmane.comp.version-control.git/110049

which would make Jeffrey's test pass, but I have a feeling it was just a simple test case and that he actually cares about real remotes.

-Peff

PS I think the "send-HEAD-explicitly" patch series was here:

     http://thread.gmane.org/gmane.comp.version-control.git/102039

   I had some complaints at the time, but re-reading it I don't see
   anything that would prevent us from revisiting the topic now.