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

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 29, 2012, 07:50 UTC
Message-ID: <7vsjizvtfo.fsf@alter.siamese.dyndns.org>
In-Reply-To: <7vwr8bvvxj.fsf@alter.siamese.dyndns.org>

Junio C Hamano <gitster@pobox.com> writes:

Show 7 quoted lines

> ...
> 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.

[sorry for having sent an incomplete message without conclusion]

The question then becomes this: what do you want to do about it with this specific case, and more importantly what do you want to do about other commands and options that would not make sense when HEAD knows what branch the user wants to put the first commit on but there is no commit yet?

For some commands, we _do_ try to come up with a special case codepath so that a command issued in the unborn state mimics the behaviour of the command issued in the normal case to various different degrees. "git pull" into an unborn branch simply resets to the other branch, for example, and while technically speaking that is not merging the other branch into the current commit (which does not exist), we do so because it was deemed to be the most sensible behaviour to parallel the normal case.

I am not sure "git checkout -b foo" (without explict HEAD [*1*]) should special case and degenerate to "symbolic-ref HEAD refs/heads/foo" when HEAD points to a nonexistent branch. The mimicking does not go far enough to satisfy people who are pedantic enough to expect "git checkout -b foo" to work when you haven't even instantiated your current branch (when you are on an already instantiated branch, after "git checkout -b foo", "git branch" output will show both foo and the branch you were on, but if you start from an unborn branch, the behaviour will be different and a pedant will notice the difference).

It may make sense to let

    $ git branch -m trunk

or even

    $ git branch -m master trunk

move away from an unborn "master'"after "git init", with a special case codepath. When you start from an instanticated branch, after a successful such renaming, the original branch will not exist, and the new branch will exist. This property would also hold true if you start from an unborn one, so it would be much better mimickery than "git checkout -b foo" case you brought up in this thread.

[Footnote]

*1* Given HEAD or $(git symbolic-ref HEAD) as the starting commit explicitly, the command should error out.