Re: Recovering from a "detached from" HEAD

[Junio C Hamano <gitster@pobox.com>]

Alyssa Ross <hi@alyssa.is> writes:

> If I detach my head, then use `git subtree add` to generate a commit,
> the output from `git status` changes from "detached at SHA" to
> "detached from SHA". The sha doesn't change, but HEAD has updated.

This is expected, and there is nothing to "recover from".  Use of
"git subtree add" should be irrelevant (iow, you should get the same
behaviour no matter _how_ you build new commits on the unnamed
branch).

    $ git checkout --detach
    $ git status -uno
    HEAD detached at 9745ede235
    $ git commit --allow-empty -m empty
    [detached HEAD bc9a31f2df] empty
    $ git status -uno
    HEAD detached from 9745ede235

The commit the message shows is meant to indicate where your unnamed
branch diverged at named branches.  Immediately after moving to the
unnamed branch by detaching the HEAD, the message says "at"; the
HEAD is pointing directly at the tip of the then-current branch and
that is where the tip of the unnamed branch is.  You can tell from
that message that you will not lose any commit if you were to check
out a named branch from that state.

After you make a commit on the unnamed branch, you have something to
lose if you were to check out a named branch from that state, as the
detached HEAD is the _only_ thing these new commits you built on top
of the fork point.  Upon seeing "HEAD detached from 9745ede235", you
could do "git log 9745ede235.." and see what you would end up losing
if you were to switch to another branch without saving them first to
a named branch.

> So my question is, what's going on here? Is this intentional behaviour,
> or a bug? How should I get my working tree back to a normal state?

There is nothing abnormal in this state while you are working on an
unnamed branch.