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

[Michael Haggerty <mhagger@alum.mit.edu>]

On 01/29/2012 07:56 AM, Junio C Hamano wrote:
> Michael Haggerty <mhagger@alum.mit.edu> writes:
> 
>> 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

All that I meant is that the one command is the equivalent of *what the
user wants and expects* in the *particular* situation that I described
[1].  I should have been clearer.

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

When git behaves differently than a typical user would expect for no
good reason, that is a bug (albeit a UI bug).  The fact that somebody
who knows the internals of git can find an excuse for the inconsistency
might be an explanation for how the bug arose but it doesn't make it
less of 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.

ISTM that this state is more special than it needs to be due to an
design flaw of git [2].  But even given the fact that this case is
special *internal* to git, there is no reason to let that specialness
leak out to the user more than necessary.

> [...]
> 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).

For me, "git checkout -b foo" means "leave the old branch in its current
state and move to a new branch that is in the same state."  If the old
branch was unborn, then it should remain unborn after the command, and I
should be moved to a new unborn branch.  Since an unborn branch in git
is not a branch, I would have no expectation that the old branch exists
after the command [3].

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

It makes sense that "git branch -m" can *also* be used to escape an
unborn master, but this command won't necessarily occur to people
accustomed to using "git checkout -b" for creating new branches.

Michael

[1] Of course, here "the user" means me :-) but I predict that other
users would feel the same.

[2] Namely that "orphan" commits have no parents, instead of having an
"empty repository" commit (something like "000000*") as parent.  By
contrast, when a new Subversion repository is created, it automatically
gets a pseudo "r0" commit that represents the empty repository.  The r0
commit can be used in the UI most places that a "real" commit can be
used.  If the 0000000 commit could be used in the same way in git, it
would remove a lot of special casing.  For example, an "unborn branch"
could be initialized pointing at 0000000.  Even if there is some deeper
reason why such a design wouldn't have worked, perhaps such a concept
could be faked for the user interface.

[3] If commit 0000000 were treated specially, then there would be no
unborn branches but only branches pointing at the empty commit.  In that
case, my expectation would change--the old branch should be left
pointing at 0000000.  But currently git has no concept of an unborn
branch that is not HEAD.

-- 
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/