Hello,

        (s017241) [/usr/src/linux-2.6] git checkout v2.6.20
        warning: You appear to be on a branch yet to be born.
        warning: Forcing checkout of v2.6.20.
        fatal: ambiguous argument 'HEAD': unknown revision or path not in the working tree.
        Use '--' to separate paths from revisions
        Cannot detach HEAD

(s017241) [/usr/src/linux-2.6] git version
git version 1.5.2.1

what is going wrong here?

        Thomas
-

[ message continues ]

Perhaps repository was set up in an unusual way by hand
(i.e. not by a clone), such that:

 1. you have HEAD pointing at a branch (e.g. 'refs/heads/master'),
 2. which does _not_ exist yet (i.e. no 'refs/heads/master'),
 3. yet you have a tag that you can try to detach your HEAD to (e.g. v2.6.20).

... well that was my initial guess, but even after setting up such a
funny repository by hand, I cannot seem to reproduce it.

-

[ message continues ]

This was on a fresh clone. What I did was:

        (s017241) [/usr/src] git clone 131.188.30.102:/scratch/tg/linux-2.6/
        Initialized empty Git repository in /usr/src/linux-2.6/.git/
        remote: Generating pack...
        remote: Done counting 496189 objects.
        remote: Deltifying 496189 objects...
        remote:  100% (496189/496189) done
        Indexing 496189 objects...
        remote: Total 496189 (delta 401610), reused 496189 (delta 401610)
        100% (496189/496189) done
        Resolving 401610 deltas...
        100% (401610/401610) donedone
        fatal: Not a valid object name HEAD

I see it. Last line. I tried to clone from a repository which itself had a
detached HEAD. Could that be the problem?

        Thomas
-

[ message continues ]

Ah, our mails crossed.

There is no reason to forbid cloning of a repository whose HEAD
is detached, but detached HEAD is a relatively recent invention,
and I would not be surprised if that was indeed the breakage,
nor nobody has hit this so far.

It's sufficiently late here so I do not think I would be able to
take a look at it tonight, though.  Sorry.

Just in case you need unblocking (although I think you know how
already), you should be able to continue with:

	$ git rev-parse v2.6.20^0 >.git/HEAD
        $ git read-tree HEAD
        $ git checkout-index -f -q -u -a

That would give you a normal detached state at v2.6.20; you
should be able to come back to your branches with usual "git
checkout".

-

[ message continues ]

Hello Junio,
sleep well! And if you want to reproduce it yourself we can e-mail
tomorrow or whenever you like.

Thanks,
        Thomas
-

[ message continues ]

Actually, that turns out to be the reason for 'maint' releases,
although it works on 'master' (hence will be in 1.5.3 later).

How did you get your repository into such a state to begin with?

-

[ message continues ]

It's kinda odd to see this thread, as I hit this issue today, as well.

If you need another test case, the cvsps git repo shows this too:

ramune/lycaeum:git: git clone  http://ydirson.free.fr/soft/git/cvsps.git
<snip checkout messages>
ramune/lycaeum:git: cd cvsps
ramune/lycaeum:cvsps: ls
ramune/lycaeum:cvsps: git checkout -f
warning: You appear to be on a branch yet to be born.
warning: Forcing checkout of HEAD.
fatal: just how do you expect me to merge 0 trees?
ramune/lycaeum:cvsps: cat .git/HEAD
ref: refs/heads/master
ramune/lycaeum:cvsps: ls .git/refs/head/master
ls: .git/refs/head/master: No such file or directory

-- DN
Daniel
-

[ message continues ]