* Solved: why cloning my repo always got the wrong default branch; possibly missing featurette?
@ 2012-04-21 8:08 Luke Diamand
2012-04-21 19:28 ` Junio C Hamano
0 siblings, 1 reply; 2+ messages in thread
From: Luke Diamand @ 2012-04-21 8:08 UTC (permalink / raw)
To: Git Users
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
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: Solved: why cloning my repo always got the wrong default branch; possibly missing featurette?
2012-04-21 8:08 Solved: why cloning my repo always got the wrong default branch; possibly missing featurette? Luke Diamand
@ 2012-04-21 19:28 ` Junio C Hamano
0 siblings, 0 replies; 2+ messages in thread
From: Junio C Hamano @ 2012-04-21 19:28 UTC (permalink / raw)
To: Luke Diamand; +Cc: Git Users
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...
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2012-04-21 19:28 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-04-21 8:08 Solved: why cloning my repo always got the wrong default branch; possibly missing featurette? Luke Diamand
2012-04-21 19:28 ` Junio C Hamano
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).