Re: Local clone checks out wrong branch based on remote HEAD

From: Daniel Barkalow <barkalow@iabervon.org>
Date: Mar 17, 2009, 19:39 UTC
Message-ID: <alpine.LNX.1.00.0903171530160.19665@iabervon.org>
In-Reply-To: <b97024a40903171219k8841508p774d9dc4295a09bc@mail.gmail.com>

On Tue, 17 Mar 2009, Tom Preston-Werner wrote:

Show 23 quoted lines

> I'm having some unexpected behavior when cloning a remote repo that
> has several branches at the same commit. On the remote side, the HEAD
> is 'trunk':
> 
> git@remote ~/repositories/akincisor/site.git $ cat HEAD
> ref: refs/heads/trunk
> 
> After cloning this with a standard `git clone`, the refs are:
> 
> [11:48][tom@solid:~/dev/sandbox/site(release)]$ git branch -r -v
>   origin/HEAD    a52528a Fixed some routing problems
>   origin/release a52528a Fixed some routing problems
>   origin/trunk   a52528a Fixed some routing problems
> 
> And the checked out branch is 'release' instead of 'trunk' as I would expect:
> 
> [11:48][tom@solid:~/dev/sandbox/site(release)]$ git branch
> * release
> 
> I'm guessing that the first branch that matches the remote HEAD
> revision is being checked out instead of the actual remote branch. I
> would expect the correct branch to be chosen regardless of where the
> branches are pointing.

Unfortunately, the current protocol version just sends:

a52528a HEAD a52528a refs/heads/release a52528a refs/heads/trunk

It doesn't transmit the fact that HEAD is a pointer to anything, or what it's a pointer to. One thing you can do is just change your local repo to point origin/HEAD where you want, and check out what you want; the defaults are just to get you started. Another thing is that it will guess "master" if there is one. I think there's also been discussion of a protocol extension to transmit the information, although I don't know where that ended up. (The protocol-agnostic transport infrastructure can represent the information, but doesn't receive it for the normal protocol)

	-Daniel
*This .sig left intentionally blank*