From: Luke Diamand <luke@diamand.org>
To: Git Users <git@vger.kernel.org>
Subject: Solved: why cloning my repo always got the wrong default branch; possibly missing featurette?
Date: Sat, 21 Apr 2012 09:08:34 +0100 [thread overview]
Message-ID: <4F926B02.3050104@diamand.org> (raw)
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
next reply other threads:[~2012-04-21 8:09 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-21 8:08 Luke Diamand [this message]
2012-04-21 19:28 ` Solved: why cloning my repo always got the wrong default branch; possibly missing featurette? Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4F926B02.3050104@diamand.org \
--to=luke@diamand.org \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.