On Sun, Jun 23, 2013 at 4:54 PM, Jonathan Nieder <jrnie...@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.

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to