Re: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-)

["Zorba" <cr@altmore.co.uk>]

> I have been using $ git reset --hard <version> as an escalator to ascend /
> descend the versions up and down

you should probably be using git checkout for this

> Surely it doesn't alter the history, as I can commit versionA, versionB,
> versionC, and then reset to A, then reset to C, then reset to B.

i does alter the history.  i think this works because git isnt'
deleting the actual blob objects in the git dir until you use the git
prune, or gc or whatever (i never use it anyway).  but, you are
altering history, and just happen to be recovering.

** Ok!, so after commit B1, versionA doesn't store a link to versionB 
natively on and of its own accord. In other words BA and C are now written 
OUT of the history, as you say. I'm relying on some cached meta data that 
allows me to go back up the version tree again (ie downstream) and write B 
and/or C back into the history, which I should not rely on having access to 
all the time. Now I'm understanding more about differences between git-reset 
and git-checkout

> so when I reset to A, I've still got the ability to get to B or C again

with an uneasy conscience ;)

** yes, if the metadata cache failed or got wiped, I'd be screwed for 
getting back to later commits
I see !
I'm relying on something that isn't part of the intrinsic design... hmmm

> 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 ?

yes! but this is not true if you had done a git checkout (there are
measures to recover B and C, provided you haven't done a prune.  i
think git reflog has some answers here, but i'm still a newbie).

> 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).

you've goofed what commit (a1?, c?, d3?)?  where are you now and what
do you want to do now? reset to what version?  if you're just worried
about space used by B and C, i think git prune will purge these (look
at man page, don't guess at the syntax).

** I goofed B, so I reset to A, and redid the edits correctly this time 
(using your tip from other post $ git add -A = thanks again!), so now am on 
B1.
Having read your notes, I am now comfortable about letting B and C hang 
around, as I realise now they are out of the official picture. Sitaram's 
comparison of a linked list helps since there is no branch/merge: B1 can 
only have one parent, which is A, so A can only have one child which is B1 
(and B and C are relying on the cached stuff to survive, so let 'em freeze 
!)

i half suspect that you want to git branch at some point, but if
yo'ure just recretaing the other code bases' history form other files,
you shouldn't be able to break too much by git reset --hard, or git
prune.

** yes I might well want to at some point, but don't want to run before 
walking. I'm the only one on this project currently, and still archiving old 
versions into git. When I get the latest one in, I may branch so I can work 
away without affecting a stable master branch.