# remote's HEAD not detected correctly 4 messages from 2011-02-28 to 2011-02-28. Participants: Jeffrey Middleton, Shawn Pearce, Jeff King, Junio C Hamano. Thread: https://gitlist.dev/t/26623 ## Jeffrey Middleton, 2011-02-28 20:52 Subject: remote's HEAD not detected correctly Message-ID: URL: https://gitlist.dev/e/AANLkTimWieViK4JcJQuTDiRiAdyvHuwkwy8fL%2BXUV%2Bi-%40mail.gmail.com ``` 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 ``` ## Shawn Pearce, 2011-02-28 21:01 Subject: Re: remote's HEAD not detected correctly Message-ID: URL: https://gitlist.dev/e/AANLkTimqTa24QSWACFX9GErt-Tn%2BwLda1s_AvH7dzEpm%40mail.gmail.com In-Reply-To: ``` On Mon, Feb 28, 2011 at 12:52, Jeffrey Middleton 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, 2011-02-28 21:42 Subject: Re: remote's HEAD not detected correctly Message-ID: <20110228214207.GA5854@sigill.intra.peff.net> URL: https://gitlist.dev/e/20110228214207.GA5854%40sigill.intra.peff.net In-Reply-To: ``` On Mon, Feb 28, 2011 at 01:01:08PM -0800, Shawn O. Pearce wrote: > On Mon, Feb 28, 2011 at 12:52, Jeffrey Middleton 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. ``` ## Junio C Hamano, 2011-02-28 23:10 Subject: Re: remote's HEAD not detected correctly Message-ID: <7vk4gjhi15.fsf@alter.siamese.dyndns.org> URL: https://gitlist.dev/e/7vk4gjhi15.fsf%40alter.siamese.dyndns.org In-Reply-To: <20110228214207.GA5854@sigill.intra.peff.net> ``` Jeff King 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. ```