Michael Haggerty <mhagger@xxxxxxxxxxxx> 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
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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html