Jeffrey Middleton | 28 Feb 21:52 2011
Picon

remote's HEAD not detected correctly

There appears to be some weirdness here - git isn't properly looking
at the HEAD of the remote repository

#!/bin/bash

(mkdir project &&
cd project &&
git init -q &&
touch a &&
git add a &&
git commit -q -m "add a" &&
git checkout -q -b pu) &&
git clone -q project project.clone &&
(cd project.clone &&
echo -n "HEAD: " && git symbolic-ref HEAD &&
echo -n "origin/HEAD: " && git symbolic-ref refs/remotes/origin/HEAD &&
git remote show origin)

The output is:

HEAD: refs/heads/master
origin/HEAD: refs/remotes/origin/master
* remote origin
  Fetch URL: /home/jefromi/sandbox/project
  Push  URL: /home/jefromi/sandbox/project
  HEAD branch (remote HEAD is ambiguous, may be one of the following):
    master
    pu
8< more git remote output 8<

(Continue reading)

Shawn Pearce | 28 Feb 22:01 2011

Re: remote's HEAD not detected correctly

On Mon, Feb 28, 2011 at 12:52, Jeffrey Middleton <jefromi <at> 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.

--

-- 
Shawn.
Jeff King | 28 Feb 22:42 2011
Picon

Re: remote's HEAD not detected correctly

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

> On Mon, Feb 28, 2011 at 12:52, Jeffrey Middleton <jefromi <at> 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.

(Continue reading)

Junio C Hamano | 1 Mar 00:10 2011
Picon
Picon

Re: remote's HEAD not detected correctly

Jeff King <peff <at> peff.net> writes:

> 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.

Good digging.

Gmane