user manual question

Under "Examining an old version without creating a new branch" subsection in 
chapter1

to aid my understanding, could the statement:

"The HEAD then refers to the SHA1 of the commit instead of to a branch, and 
git branch shows that you are no longer on a branch:"

be restated more explicitly as:

"The HEAD then refers to the SHA1 of the commit instead of to a branch head, 
and git branch shows that you are no longer on a branch head:"

?

On 2008-12-28, Zorba [off-list ref] wrote:

Under "Examining an old version without creating a new branch" subsection in 
chapter1

to aid my understanding, could the statement:

"The HEAD then refers to the SHA1 of the commit instead of to a branch, and 
git branch shows that you are no longer on a branch:"

be restated more explicitly as:

"The HEAD then refers to the SHA1 of the commit instead of to a branch head, 
and git branch shows that you are no longer on a branch head:"

Sure, but I prefer "tip"; reduces confusion between "head"
and "HEAD" in spoken descriptions (I teach internal classes
on git occasionally, once even on a conf call!)

The git glossary makes no mention of "tip", so this is
probably "unblessed" :-)

On Sun, Dec 28, 2008 at 8:08 PM, [off-list ref] wrote:

On 2008-12-28, Zorba [off-list ref] wrote:

quoted

Under "Examining an old version without creating a new branch"
subsection in chapter1

to aid my understanding, could the statement:

"The HEAD then refers to the SHA1 of the commit instead of to a
branch, and git branch shows that you are no longer on a branch:"

be restated more explicitly as:

"The HEAD then refers to the SHA1 of the commit instead of to a
branch head, and git branch shows that you are no longer on a branch
head:"

Sure, but I prefer "tip"; reduces confusion between "head" and "HEAD"
in spoken descriptions (I teach internal classes on git occasionally,
once even on a conf call!)

+1

I was (am) was initially confused about head and HEAD and assumed that
they are both same.

-- dm

Hi Sitaram!

Thanks for clearing that one up.

Also, I did wonder about HEAD and head. One can move, the other doesn't! 
(well, acually it does - head moves "forward", as the tip of the branch 
grows)

you gotta love it
:-)

Thanks for your other post/reply too - I will be getting back to you on that 
one

Conor

"Sitaram Chamarty" [off-list ref] wrote in message 
news:slrnglf3qh.c7j.sitaramc@sitaramc.homelinux.net...

On 2008-12-28, Zorba [off-list ref] wrote:

quoted

Under "Examining an old version without creating a new branch" subsection 
in
chapter1

to aid my understanding, could the statement:

"The HEAD then refers to the SHA1 of the commit instead of to a branch, 
and
git branch shows that you are no longer on a branch:"

be restated more explicitly as:

"The HEAD then refers to the SHA1 of the commit instead of to a branch 
head,
and git branch shows that you are no longer on a branch head:"

Sure, but I prefer "tip"; reduces confusion between "head"
and "HEAD" in spoken descriptions (I teach internal classes
on git occasionally, once even on a conf call!)

The git glossary makes no mention of "tip", so this is
probably "unblessed" :-)

Hi Dilip,

Thanks for sharing that. It makes me feel not so stupid :-)

regards

+1

I was (am) was initially confused about head and HEAD and assumed that
they are both same.

-- dm 

On 2008-12-29, Zorba [off-list ref] wrote:

Hi Sitaram!

Thanks for clearing that one up.

you're welcome; we've all done a bit of struggling I guess!

Also, I did wonder about HEAD and head. One can move, the other doesn't! 
(well, acually it does - head moves "forward", as the tip of the branch 
grows)

Here's an extract from my notes/internal talks on this:

    === basic concepts
      * a branch is "an active line of development"
      * //master//: default branch in a project, by convention
      * //head//: tip of a branch
      * a repo can track many branches, but the working tree is associated with
        only one branch at a time
      * //HEAD//: tip of the branch associated with the working tree; this is
        where commits go
        ** except when it's "detached"

Thanks for your other post/reply too - I will be getting back to you on that 
one

Glad to be of help.  I don't consider myself a guru, and am
constantly waiting for one of the real gurus to strike me
down with a thunderbolt for saying something stupid :-)

On Mon, Dec 29, 2008 at 6:42 AM, [off-list ref] wrote:

On 2008-12-29, Zorba [off-list ref] wrote:

quoted

Hi Sitaram!

Thanks for clearing that one up.

you're welcome; we've all done a bit of struggling I guess!

quoted

Also, I did wonder about HEAD and head. One can move, the other
doesn't!  (well, acually it does - head moves "forward", as the tip
of the branch grows)

Here's an extract from my notes/internal talks on this:

   === basic concepts      * a branch is "an active line of
development"      * //master//: default branch in a project, by
convention      * //head//: tip of a branch      * a repo can track
many branches, but the working tree is associated with        only one
branch at a time      * //HEAD//: tip of the branch associated with
the working tree; this is        where commits go        ** except
when it's "detached"

That's a nice,compact and effective  note. Thanks for sharing :-)
Consider pushing the full notes to GITHUB...would be _useful_ for all of
us..(like me)...


-- dm

so a detached HEAD is just a HEAD that is not sitting on a tip ?

i.e. if I do $ git reset --hard HEAD^

...pointing HEAD to the previous committ

this is a detached HEAD

(I thought a detached HEAD was maybe a head somewhere on another branch not 
"reachable", i.e. a sibling, not a ancestor...
or something like that)


thanks guys

"Sitaram Chamarty" [off-list ref] wrote in message 
news:slrnglg90m.olt.sitaramc@sitaramc.homelinux.net...

On 2008-12-29, Zorba [off-list ref] wrote:

quoted

Hi Sitaram!

Thanks for clearing that one up.

you're welcome; we've all done a bit of struggling I guess!

quoted

Also, I did wonder about HEAD and head. One can move, the other doesn't!
(well, acually it does - head moves "forward", as the tip of the branch
grows)

Here's an extract from my notes/internal talks on this:

   === basic concepts
     * a branch is "an active line of development"
     * //master//: default branch in a project, by convention
     * //head//: tip of a branch
     * a repo can track many branches, but the working tree is associated 
with
       only one branch at a time
     * //HEAD//: tip of the branch associated with the working tree; this 
is
       where commits go
       ** except when it's "detached"

quoted

Thanks for your other post/reply too - I will be getting back to you on 
that
one

Glad to be of help.  I don't consider myself a guru, and am
constantly waiting for one of the real gurus to strike me
down with a thunderbolt for saying something stupid :-)

On 2008.12.29 16:38:30 -0000, Zorba wrote:

so a detached HEAD is just a HEAD that is not sitting on a tip ?

i.e. if I do $ git reset --hard HEAD^

...pointing HEAD to the previous committ

this is a detached HEAD

No. At least that won't turn an "attached" HEAD into a detached HEAD.

Attached HEAD: HEAD is a symbolic ref to another ref.
Detached HEAD: HEAD is a non-symbolic ref to a commit.

So you can have:
HEAD -> refs/heads/master -> commitA  --> attached HEAD

Or:
HEAD -> commitA --> detached HEAD

Note how the commit object is the same in both cases.

What you "git reset [--hard] HEAD^" does, depends on the kind of HEAD
you have.

"git reset HEAD^" will (conceptually, implementation might differ):

Resolve HEAD^ to find a commit.

and

Resolve HEAD until it finds a non-symbolic ref, and update that ref to
reference the commit it found.

Looking at the cases from above:

Attached case:
HEAD -> refs/heads/master -> commitA

Resolve HEAD^:
HEAD^ ==> refs/heads/master^ ==> commitA^ ==> commitA_parent

Find non-symbolic ref:
HEAD (symbolic) ==> refs/heads/master (non-symbolic)

So refs/heads/master gets updated to reference commitA_parent.


Now the detached case:
HEAD -> commitA

Resolve HEAD^:
HEAD^ ==> commitA^ ==> commitA_parent

Find non-symbolic ref:
HEAD (non-symbolic)

So HEAD gets updated to reference commitA_parent.


In other words, HEAD is what tells git what you have checked out. And
that's either a branch head (attached HEAD, symbolic ref) or a commit
(detached HEAD, non-symbolic ref).

In the symbolic ref case, operations like "commit" or "reset" work on
the branch you have checked out (found through the symbolic ref), in the
non-symbolic ref case (detached HEAD), those operations work on HEAD
itself.

Björn

Zorba, 29.12.2008:

so a detached HEAD is just a HEAD that is not sitting on a tip ?

You can also get a detached HEAD with "git checkout origin/master",
although your HEAD points to a tip. But it's a remote tip and since you
can't work on remote branches, you now are on a detached HEAD (no
branch).

i.e. if I do $ git reset --hard HEAD^

...pointing HEAD to the previous committ

this is a detached HEAD

No, this isn't. "git reset <commit>" modifies your current head (local
branch), now HEAD still points to the tip, but the tip is one commit
older. A detached HEAD you can get with "git checkout HEAD^".

On 2008-12-29, Zorba [off-list ref] wrote:

so a detached HEAD is just a HEAD that is not sitting on a tip ?

yes...

i.e. if I do $ git reset --hard HEAD^

...pointing HEAD to the previous committ

this is a detached HEAD

...but no.  This is because git reset moves the tip of the
branch also (in this case, backward by one commit from the
previous).  In effect, you're saying "discard my latest
commit and roll back by one".

"git checkout HEAD^" would get you a detached head though.
In this case you're saying "let the branch be where it is,
but let HEAD move up one level".  So HEAD is now NOT at a
tip, and it'a a detached head.

It's instructive to run "gitk --all" when you're doing these
experiments sometimes.

(I thought a detached HEAD was maybe a head somewhere on another branch not 
"reachable", i.e. a sibling, not a ancestor...
or something like that)

no no that's just another branch that's all.

All this is pretty confusing in the beginning, but if you
don't lose your head, it'll all become clear eventually.

[What's that they say?  Oh yeah "thank you ladies and
gentlemen I'll be here all night"!]

On Mon, 29 Dec 2008, Zorba wrote:

so a detached HEAD is just a HEAD that is not sitting on a tip ?

If you used CVS (extensively) back in the day, a detached HEAD is like 
what you get if you do something like "cvs checkout -D yesterday" (CVS 
called it "sticky tags"); you have a working directory that contains some 
revision that isn't your latest revision. If you make changes, they can't 
go into the history in the normal fashion, but you can build the project 
and figure out how it worked back then.

With git, of course, you can do things you couldn't do from that state 
with CVS. Because git supports forking history, you can make commits and 
create a new branch to be on. Because git can handle having visibility 
into other people's branches, you can get a detached HEAD by checking out 
somebody else's branch (something like origin/next, for example).

The normal "attached HEAD" state is that there's some branch that you 
update when you make a commit; the "detached HEAD" state means that, when 
you make a commit, no branch is affected.

i.e. if I do $ git reset --hard HEAD^

...pointing HEAD to the previous committ

this is a detached HEAD

Nope, it's "git checkout (something that isn't one of your branches)", 
just like CVS.

Git is like knitting. Commits are loops of yarn that hold other loops 
(their parents) in place; branches are knitting needles that keep new 
loops from falling out before other loops are holding them, and which hold 
different loops at different times as you work; HEAD is the tip of a 
needle that you use to make new loops. You usually use the tip of one of 
your regular needles to make new loops, and then the body of the needle 
holds the loop, but you could also use your fingers or something that will 
just make the loop temporarily; that's a detached HEAD, because it doesn't 
have the body of a needle behind it to hold loops when you use it for 
something else.

	-Daniel
*This .sig left intentionally blank*