Re: detached HEAD before root commit - possible?

From: Martin von Zweigbergk <martinvonz@gmail.com>
Date: Jun 24, 2013, 04:20 UTC
Message-ID: <CANiSa6jNjCDjj_ZD7COXyDUx9DxFpuVqT-Lm24KQVMDK=serpw@mail.gmail.com>
In-Reply-To: <20130623235432.GA3024@elie.Belkin>

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

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

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