user manual question

user manual question

[Zorba]

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:"

?

Re: user manual question

[Sitaram Chamarty]

On 2008-12-28, Zorba <cr@altmore.co.uk> 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" :-)

Re: user manual question

[Dilip M]

On Sun, Dec 28, 2008 at 8:08 PM, <sitaramc@gmail.com> wrote:
> On 2008-12-28, Zorba <cr@altmore.co.uk> 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!)

+1

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

-- dm

Re: user manual question

[Zorba]

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" <sitaramc@gmail.com> wrote in message 
news:slrnglf3qh.c7j.sitaramc@sitaramc.homelinux.net...
> On 2008-12-28, Zorba <cr@altmore.co.uk> 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" :-)
> 

Re: user manual question

[Zorba]

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 

Re: user manual question

[Sitaram Chamarty]

On 2008-12-29, Zorba <cr@altmore.co.uk> 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 :-)

Re: user manual question

[Dilip M]

On Mon, Dec 29, 2008 at 6:42 AM, <sitaramc@gmail.com> wrote:
> On 2008-12-29, Zorba <cr@altmore.co.uk> 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"

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

Re: user manual question

[Zorba]

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" <sitaramc@gmail.com> wrote in message 
news:slrnglg90m.olt.sitaramc@sitaramc.homelinux.net...
> On 2008-12-29, Zorba <cr@altmore.co.uk> 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 :-)
> 

Re: user manual question

[Björn Steinbrink]

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

Re: user manual question

[Markus Heidelberg]

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^".

Re: user manual question

[Sitaram Chamarty]

On 2008-12-29, Zorba <cr@altmore.co.uk> 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"!]

Re: user manual question

[Daniel Barkalow]

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*