detached HEAD before root commit - possible?

I suspect that detaching HEAD before a root commit is not possible by design. What would HEAD contain then!? 'git checkout' seems to corroborate:

$ git init Initialized empty Git repository in /tmp/test/.git/ $ git checkout --detach fatal: You are on a branch yet to be born

Are there some plumbing commands and options that would still allow this, or can I rely on that that it's impossible?

Thanks, Gábor

Hi,

SZEDER Gábor wrote:

gitrepository-layout(5) tells me HEAD can be in one of a few states:

 a) Missing.  In this case the repository is considered to be
    corrupt and attempts to access the repository fail until the user
    runs "git init" to recover.

 b) A symbolic link, which is one way to represent a symref (pointing
    to an existing branch or an unborn branch).

 c) A standard symref, in the format "ref: refs/some/branch".  Behaves
    like (b).

 d) A direct SHA-1 reference (40-character commit object name)
    pointing to a commit without associating a branch ("detached HEAD").

 e) Anything else means the repository is corrupt, as in case (a).

In other words, HEAD always either points to an unborn or existing branch or an existing commit. It's not clear to me what it would mean to detach from an unborn branch.

Improvements to the documentation to make that clearer would of course be welcome. ;-)

Thanks, Jonathan

On Sun, Jun 23, 2013 at 4:54 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:

I think it should mean that the next commit would be a root commit (of course) and that HEAD would be detached and point to that commit. I find that it helps to think of unborn branches (and "unborn" detached HEAD) as pointing to some fixed root commit.

I wanted an "unborn detached HEAD" once when working on rebase. Imagine what "git rebase --root" would do when run on a detached HEAD. It is currently slightly broken because it forces the rebase (i.e. creates a new root commit). This is inconsistent with e.g. "git rebase HEAD~10", which won't do anything (assuming linear history). It would have been nice if "git rebase --root" could be implemented as:

 1. create unborn detached HEAD
 2. cherry-pick commits
 3. set branch (or not, if started from detached HEAD)

Instead, what I ended up doing at some point was to create a temporary unborn branch that I deleted after picking the first commit.

Anyway, that was just to show another point of view; I'm not suggesting we should implement support for unborn detached HEAD.

Martin

Martin von Zweigbergk <martinvonz@gmail.com> writes:

Yup.  As Jonathan outlined how the current system works:

 - $GIT_DIR/HEAD could be a symref to a branch, which may or may not
   exist (the latter being "unborn"); or

 - $GIT_DIR/HEAD could be directly pointing at an existing commit,
   which is the definition of "detached", as you "detach HEAD at
   that commit".

even though such a "I do not have any commit and I will not be on any branch" state were to be supported, the consequence of that would be that a natural implementation of such a state is to represent it by not having $GIT_DIR/HEAD at all. That will break quite a lot of things, as such a directory $GIT_DIR will not be treated as a git directory in the first place. Of course, you could fix them up to support it, but I doubt if it is worth the trouble.

SZEDER Gábor <szeder@ira.uka.de> writes:

Is "git checkout --orphan" what you're looking for?