Re: RFC for 1.7: Do not checkout -b master origin/master on clone

[Junio C Hamano <gitster@pobox.com>]

Michael J Gruber <git@drmicha.warpmail.net> writes:

> One common source of confusion for newcomers is the fact that master is
> given such a special treatment in git. While it is certainly okay and
> helpful to set up a default branch in a new repository (git init) it is
> not at all clear why it should be treated specially in any other
> situation, such as:
>
> - Why is master the only local branch which git clone sets up (git
> checkout -b master origin/master)?

As you know it is not strictly "master".  It is the primary branch at the
cloned repository, which by convention is master", but whatever remote end
points at with its HEAD.

We check out that primary branch to make it easy for people to work with
the simplest kind of CVS/SVN-like settings, which I suspect is 99% of
peoples' projects.  Single "trunk" that is checked out immediately after
cloning from a distribution point (read: a bare repository) ready to be
used.

> - Why does git svn set up a local branch with an svn upstream which is
> determined by latest svn commit at the time of the first git svn fetch?

I do not have comments on design decisions in git-svn, other than trusting
that Eric would exercise good design tastes to make things coherent with
the git native workflow when the consistency makes sense.

> ..., and git clone
> sets up a local branch according to HEAD (and does some other guess work
> when cloning bare repos), which means that git clone shows the same
> "random" behaviour...

It is because you are cloning from a repository that is used actively to
build new history, flipping the HEAD left and right.  That is where the
randomness comes from.  IOW, a repository with an active work tree.

If you are cloning because you have your own private working area and you
would want to get another private working area to work simultaneously, you
have "clone -n && checkout -t origin/whatever".  Also if you are doing
this on a local machine (which is somewhat common), there is new-workdir
script in contrib/.  But this is _not_ the most common case we should
optimize the usability of "clone" for.