Re: Bug: "git checkout -b" should be allowed in empty repo

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 29, 2012, 06:56 UTC
Message-ID: <7vwr8bvvxj.fsf@alter.siamese.dyndns.org>
In-Reply-To: <4F24E287.3040302@alum.mit.edu>

Michael Haggerty <mhagger@alum.mit.edu> writes:

Show 15 quoted lines

> When starting a new repo, git seems to insist that the first commit be
> made on a branch named "master":
>
>     $ git --version
>     git version 1.7.9
>     $ git init git-test
>     Initialized empty Git repository in /home/mhagger/tmp/git-test/.git/
>     $ cd git-test
>     $ git checkout -b foo
>     fatal: You are on a branch yet to be born
>
> I would call this a bug; the last command should be allowed.  The
> plumbing allows it:
>
>     $ git symbolic-ref HEAD refs/heads/foo

Your last sentence is nonsense. The plumbing equivalent of that command is *not* what you wrote above, but is more like [*1*]:

	git update-ref refs/heads/foo $(git rev-parse --verify HEAD) &&
        git symbolic-ref HEAD refs/heads/foo

And the first step will fail the same way. While I share the sense of annoyance with you, I do not think that it is a bug in "checkout -b".

When you are on an unborn branch, what the "symbolic-ref HEAD" command reports does *not* appear in the output from the "for-each-ref refs/heads" command (similarly, that branch name does not appear in the output from the "git branch" command).

Such a behaviour indeed is *curious* and very *different* from the normal case of being on an existing branch, but is that a bug?

You need to first admit that the state immediately after "git init" (or for that matter, "checkout --orphan") where you are on an unborn branch *is* special. Some things that would normally make sense would not.

[Footnote]

*1* Because you are not switching to a different commit, there won't be a need for the third step which is "git read-tree -m -u HEAD@{1} HEAD" that would usually be necessary if you are giving a starting commit that is different from HEAD.