views:

19

answers:

1

I'm not finding my answer in the online git lit.

It is clear that git checkout is destructive in that it will throw away local modifications but does it also destroy commits by changing the structure of the tree? For example, say I have three commits

a <-- b <-- c
            |
           HEAD

+ stash c

and HEAD is currently at c and I've stashed all uncommitted changes.

If I do "git checkout HEAD^" I would naively expect this to take me from one head to another i.e. the state of the tree should be:

a <-- b <-- c
      |
     HEAD

+ stash b

where "stash b" is whatever was stashed at commit b.

But it seems from my experimentation that the actual result is

a <-- b
      |
     HEAD

+ stash b

i.e. commit c is "pruned" from the tree or is at least not showing up in "git log".

Am I getting this completely wrong? Is the answer to this question obvious from the git manuals?

A: 

A commit doesn't reference the child, only the parent. And more than one child can have the same parent.

Tass
So I think the answer is that "checkout" should be viewed as a traversal of the tree plus a pruning since all the children are lost permanently. This is not emphasized. "Not referencing" and "Erasing" are different things entirely.
mathtick
Ok, now I see. git checkout only moves HEAD and not "master". git log master shows the full branch.
mathtick