All of lore.kernel.org
 help / color / mirror / Atom feed
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





	

             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.