On Tue, 17 Mar 2009, Tom Preston-Werner wrote: > 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* -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
