Re: detached HEAD before root commit - possible?

2013-06-24 Thread Matthieu Moy
SZEDER Gábor sze...@ira.uka.de 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?

2013-06-23 Thread Jonathan Nieder
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


Re: detached HEAD before root commit - possible?

2013-06-23 Thread Martin von Zweigbergk
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.

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?

2013-06-23 Thread Junio C Hamano
Martin von Zweigbergk martinv...@gmail.com writes:

 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.

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