remote's HEAD not detected correctly

[Jeffrey Middleton]

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<

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?


Jeffrey
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Shawn Pearce]

On Mon, Feb 28, 2011 at 12:52, Jeffrey Middleton <[hidden email]> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Jeff King]

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

> On Mon, Feb 28, 2011 at 12:52, Jeffrey Middleton <[hidden email]> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Junio C Hamano]

Jeff King <[hidden email]> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html