On Sun, Jun 23, 2013 at 4:54 PM, Jonathan Nieder <jrnieder@xxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html