Hi Conor,
On 2008-12-30, Zorba <cr@xxxxxxxxxxxxx> wrote:
> so when I reset to A, I've still got the ability to get to B or C again
if this is true... (call this case 1)
> Now I appreciate that if I commit a new change from versionA (lets call it
> B1), then HEAD is now at B1, and B, C etc are lost, correct ?
...then this (call this case 2) is not true.
In case 1, *how* do you get back to B and C? However you do
it, the same action will get you to B and C *after* you
created B1 as well.
It might help to think of these things loosely using a
malloc/linked-list analogy. Imagine a singly-linked list,
and a variable in your program called "head" pointing to the
top element. Each element contains a back-pointer to its
parent. You can start from head and walk the list backward,
but you can't walk forward -- there are no forward pointers.
A "git commit" is analogous to:
newblkptr = malloc(...);
... store whatever you want in the new block ...
newblkptr.backptr = head;
head = newblkptr;
i.e., a classic linked list add.
A "git reset --hard HEAD^" essentially pops the topmost
element off the list:
head = head.backptr
A "git checkout -f HEAD^" is like walking a linked list
backward in a loop, and stopping at some intermediate block
to do something -- other the temporary loop-variable,
nothing else (no global variable perhaps) points to this
block, so this is like a detached head.
Of course, nothing prevents you from permanently saving this
temporary loop variable because you suddenly realise *this*
link in the chain is very important for the rest of your
program:
some_global_var = temp_blk_ptr;
This is like "git checkout -b newbranch" does.
> Its pertinent to where I am right now, as I've goofed a commit, and want to
> reset, and commit again but I'm worried about leaveing garbage lying around
> (the commits for version B and C in the example above).
(1) never worry about leaving garbage around; there are many
operations that do that; it's part of the design. Don't
sweat it.
(2) when in doubt, try "gitk --all". That's a good GUI.
I'm normally a CLI freak, but when something needs to be
understood/learnt, a well-designed GUI really helps.
Run "gitk --all" on the side and hit F5 on it after each
operation on the command line -- helped me when I was trying
to figure out what's happening.
PS: although it doesn't mention detached heads,
http://eagain.net/articles/git-for-computer-scientists/
helped me a lot...
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
