Re: detached HEAD before root commit - possible?
SZEDER Gábor writes: > 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 Is "git checkout --orphan" what you're looking for? -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- 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
Re: detached HEAD before root commit - possible?
Martin von Zweigbergk writes: > On Sun, Jun 23, 2013 at 4:54 PM, Jonathan Nieder 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. 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. -- 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
Re: detached HEAD before root commit - possible?
On Sun, Jun 23, 2013 at 4:54 PM, Jonathan Nieder 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: detached HEAD before root commit - possible?
Hi,
SZEDER Gábor wrote:
> $ 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?
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
--
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
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 -- 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
