git clone operation

I'm trying to understand git-clone and what to expect when I clone a repository. Disclaimer, I am a newbie :).

Assume I have a repo with the following branches:

  cpu-intfc
  gige_mux
  improve-build
  main-devel
* master

According to the man page, git-clone "creates and checks out an initial branch equal to the cloned repository's currently active branch."

So, when I clone this repo and run 'git-branch -a' I will have the following:

  origin/HEAD
  origin/cpu-intfc
  origin/gige_mux
  origin/improve-build
  origin/main-devel
  origin/master
* master

All the origin/* branches are remote.

And, .git/refs/remotes/origin/HEAD is, 

$ cat .git/refs/remotes/origin/HEAD ref: refs/remotes/origin/master

So far, this makes sense to me.

Now, let's say that I am working in the cpu-intfc branch of the original repository and I clone the repository.

Running git-branch -a returns the following

  origin/HEAD
  origin/cpu-intfc
  origin/gige_mux
  origin/improve-build
  origin/main-devel
  origin/master
* cpu-intfc

And this,

$ cat .git/refs/remotes/origin/HEAD ref: refs/remotes/origin/cpu-intfc

I was expecting to have a local branch named master (that is equal to the remote branch origin/cpu-intfc) instead of cpu-intfc. Am I wrong to expect this? Also, as a newbie user, it seems odd that I cannot specify which branch of repo that I am cloning should be the default (master) branch of the cloned repo? To put it another way, when cloning a repo I have no way of controlling which branch I get as the default. It just happens to depend on which branch the developer is working in at the time I clone. I've read through the man-page and there doesn't seem to be any way around this.

I realize that I can create a new local branch that is based off the desired branch:

$ git-checkout -b master origin/master

Is this the accepted method for obtaining the desired branch?

Thanks, Mike

Mike Gant <mwgant@gmail.com> writes:

[...]

[...]

Currently the situation is a bit strange, because while git-remote supports selecting which branch is meant to be remote-tracking master branch via '-m <master>' option to "add" subcommand (setting origin/HEAD symref), git-clone which is init + remote + fetch + some bookkeeping and shortcuts doesn't.

Both commands are now built-in.

You can use (with new anough Git)

  $ git checkout --track -b master origin/master

to setup repository in such way that "git pull" on 'master' would know that it is meant to fetch from 'origin' and merge 'origin/master'.

In upcoming 1.6.1 it would be enough to use

  $ git checkout --track origin/master

On 2008.08.17 12:23:57 -0700, Jakub Narebski wrote:

branch.autosetupmerge is set to true by default, so for remote branches --track is the default anyway (since 1.5.5 IIRC). So only an old enough git would actually require --track, unless you changed the config ;-)

Björn

On Sun, Aug 17, 2008 at 1:38 PM, Björn Steinbrink <B.Steinbrink@gmx.de> wrote:

Thanks for your responses. I appreciate you guys taking the time to answer.

After thinking about this, I still don't understand when I clone a repo why I will get the equivalent of whatever branch is active at the time of cloning? What was the process that led to this design decision?

So that also got me thinking about work flows with git. Because of the way clone works it seems that you wouldn't want someone to clone your every day "work" repository? So do developers generally have a separate repository that they push to and others can clone? This repository may have only a 'master' branch (but probably others I seem to recall Junio describing other branches in the main git repository). Is this a 'normal' work flow?

Thanks, Mike Gant

Also, I meant to add if the above work flow is the git way of development, is this the purpose of a bare repository?