# Solved: why cloning my repo always got the wrong default branch; possibly missing featurette?

2 messages from 2012-04-21 to 2012-04-21. Participants: Luke Diamand, Junio C Hamano.
Thread: https://gitlist.dev/t/30301

## Luke Diamand, 2012-04-21 08:08

Subject: Solved: why cloning my repo always got the wrong default branch; possibly missing featurette?
Message-ID: <4F926B02.3050104@diamand.org>
URL: https://gitlist.dev/e/4F926B02.3050104%40diamand.org

```
I've been wondering for a while why it is that when I clone one 
particular repo, I always end up with HEAD pointed to origin/master 
regardless of what HEAD *actually* points at (unless I explicitly set 
the branch I want to checkout on the command line).

i.e.

<on myremote>
git symbolic-ref HEAD refs/heads/dev

<on client>
% git clone git://myremote/myrepo
% git branch
* master
% git branch -r
origin/HEAD -> origin/master
origin/foo
origin/bar
origin/dev
...


That doesn't seem right - I thought that setting HEAD on the remote wit 
git symbolic-ref would set the branch that gets cloned?

Here's what's happening.

git fetches the remote refs. But the field *symref* does not get filled 
in (at least for git:// and ssh://). So git gets a list of remote refs 
(HEAD, refs/heads/foo, etc) with no information about whether they are 
real heads or symrefs.

In wanted_peer_refs(), since I haven't given a branch on the 
command-line, it then calls guess_remote_head().

guess_remote_head() would get the right answer if head->symref was set:

/*
  * Some transports support directly peeking at
  * where HEAD points; if that is the case, then
  * we don't have to guess.
  */


But in my case it isn't so it then goes and just looks for a head that 
has the right SHA1.

Unfortunately, my remote 'master' branch and the branch I *really* want 
to use both usually have the same SHA1. That's because my repo is doing 
git/p4 mirroring. So the branch I want to use by default ("dev") is 
being constantly rebased (people push to it and git-p4 then does magic 
on it after which it matches master again).

i.e. the guess_remote_head() works fine if the branch you want doesn't 
have the SHA1 as origin/master, but gets it wrong if it does.

I imagine that occasionally when I clone at just the right moment, I 
*will* get the branch I was expecting!

At a guess, the protocol would need to be changed to put the symbolic 
ref information in somehow (upload-pack.c, send-refs() ?).

Is this a bug, or a feature?

Thank,
Luke





	

```

## Junio C Hamano, 2012-04-21 19:28

Subject: Re: Solved: why cloning my repo always got the wrong default branch; possibly missing featurette?
Message-ID: <xmqq7gx8zxyh.fsf@junio.mtv.corp.google.com>
URL: https://gitlist.dev/e/xmqq7gx8zxyh.fsf%40junio.mtv.corp.google.com
In-Reply-To: <4F926B02.3050104@diamand.org>

```
Luke Diamand <luke@diamand.org> writes:

> At a guess, the protocol would need to be changed to put the symbolic
> ref information in somehow (upload-pack.c, send-refs() ?).
>
> Is this a bug, or a feature?

Known protocol limitation, as you already seem to have discovered.
I think I outlined a possible protocol extension in a message a few
years ago, but nobody seemed to be interested/motivated enough, so...

```