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

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

[Zorba]

Here is a little exercise / tutorial / warm-up for someone starting out with 
Git. If you're anyting like me you may find the tutorials etc. on git.or.cz 
a bit daunting. I recommend you try this after reading the user manual but 
before tearing your hair out trying to follow all the examples in the user 
manual. After you've followed this simple workflow, then go back to the more 
advanced stuff  in the tutorials and user manuals (like cloning repositories 
and creating and merging branches).

I created this exercise to try and model our workflow and what we wanted to 
use git for = tracking a project with multiple files where the filebase 
might change frequently from one version to the next.

http://siliconmouth.wordpress.com/category/nerdy/

look for December 27, 2008 or "git warmup" 

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

[Zorba]

tidied up the formatting, added a few more comments where needed, fixed 
errors/lack of clarity

"Zorba" <cr@altmore.co.uk> wrote in message 
news:gj68a0$u56$3@ger.gmane.org...
> Here is a little exercise / tutorial / warm-up for someone starting out 
> with Git. If you're anyting like me you may find the tutorials etc. on 
> git.or.cz a bit daunting. I recommend you try this after reading the user 
> manual but before tearing your hair out trying to follow all the examples 
> in the user manual. After you've followed this simple workflow, then go 
> back to the more advanced stuff  in the tutorials and user manuals (like 
> cloning repositories and creating and merging branches).
>
> I created this exercise to try and model our workflow and what we wanted 
> to use git for = tracking a project with multiple files where the filebase 
> might change frequently from one version to the next.
>
> http://siliconmouth.wordpress.com/category/nerdy/
>
> look for December 27, 2008 or "git warmup"
>
> 

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

[Jeff Whiteside]

hi zorb,

you have done a great justice here to inadvertently explaining the
learning curve of git, through a few mistakes, especially for ppl
behind in their scm use.  i enjoyed reading your blog posts though, as
they remind me of myself, not long ago.

you have a couple of mistakes i think you should correct.

-"Imagine a project with 4 versions, made up of various configurations
of the three files."
this line implies that you have branches (the word configurations).
you should be focusing, at first, on a project that has a set number
of files, and the content merely changes.  ideally, you don't often
add and rm files across versions.  also, the project doesn't really
have 4 versions, like windows has 4 different versions of vista, the
project has 3 old versions and 1 new version.

"Setup a git index in the project directory"
-this implies you're talking about the index.  you're not.  you're
talking about the repository.  either make it clear that the index is
an intermediary staging area, or ignore its existence and change all
git-add && git-commit references to git-commit -a references.  this
will ease the user of older scms into git.

-"Rollback to each of the versions, starting with version A"
this is bad.  you're saying rollback.  to others that have used scms,
this will mean, "retrieve an older copy", but in git, this is DELETING
all the versions after the version that you "rollback" to.  your blog
post shouldn't discuss the git-reset --hard command at all, since
you're rewriting history, which is dangerous.  afaik, most scms don't
allow you to rewrite history.  to "rollback" to an older version you
should use checkout the git-checkout command.  maybe the git reset
-–hard HEAD is okay to include... but it won't be immediately obvious
to new users why it does what it does... this nomenclature was likely
not the best choice whenever it was made.


gl with your gitting.

whiteside




u're talking sdf




On Sat, Dec 27, 2008 at 5:29 PM, Zorba <cr@altmore.co.uk> wrote:
>
> tidied up the formatting, added a few more comments where needed, fixed
> errors/lack of clarity
>
> "Zorba" <cr@altmore.co.uk> wrote in message
> news:gj68a0$u56$3@ger.gmane.org...
> > Here is a little exercise / tutorial / warm-up for someone starting out
> > with Git. If you're anyting like me you may find the tutorials etc. on
> > git.or.cz a bit daunting. I recommend you try this after reading the user
> > manual but before tearing your hair out trying to follow all the examples
> > in the user manual. After you've followed this simple workflow, then go
> > back to the more advanced stuff  in the tutorials and user manuals (like
> > cloning repositories and creating and merging branches).
> >
> > I created this exercise to try and model our workflow and what we wanted
> > to use git for = tracking a project with multiple files where the filebase
> > might change frequently from one version to the next.
> >
> > http://siliconmouth.wordpress.com/category/nerdy/
> >
> > look for December 27, 2008 or "git warmup"
> >
> >
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Zorba]

Hi Jeff,

Thanks for your contrib. I'll pick these up for sure, but right now I'm 
despo to make some progress getting this confounded real-life project 
versioned.

But where I'm stuck now touches on your post.

I've just made a commit I want to retract.

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

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

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 ?

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

NB if you read my latest posts you will see why I chose the example I did 
for my "warm-up" as it closely models what I'm trying to do for real.


BTW: sdf=Syntax Definition Formalism?

"Jeff Whiteside" <jeff.m.whiteside@gmail.com> wrote in message 
news:3ab397d0812291505v77824e6fvdecebc80f38a5f89@mail.gmail.com...

-"Rollback to each of the versions, starting with version A"
this is bad.  you're saying rollback.  to others that have used scms,
this will mean, "retrieve an older copy", but in git, this is DELETING
all the versions after the version that you "rollback" to.  your blog
post shouldn't discuss the git-reset --hard command at all, since
you're rewriting history, which is dangerous.  afaik, most scms don't
allow you to rewrite history.  to "rollback" to an older version you
should use checkout the git-checkout command.  maybe the git reset
-–hard HEAD is okay to include... but it won't be immediately obvious
to new users why it does what it does... this nomenclature was likely
not the best choice whenever it was made.


gl with your gitting.

whiteside




u're talking sdf




On Sat, Dec 27, 2008 at 5:29 PM, Zorba <cr@altmore.co.uk> wrote:
>
> tidied up the formatting, added a few more comments where needed, fixed
> errors/lack of clarity
>
> "Zorba" <cr@altmore.co.uk> wrote in message
> news:gj68a0$u56$3@ger.gmane.org...
> > Here is a little exercise / tutorial / warm-up for someone starting out
> > with Git. If you're anyting like me you may find the tutorials etc. on
> > git.or.cz a bit daunting. I recommend you try this after reading the 
> > user
> > manual but before tearing your hair out trying to follow all the 
> > examples
> > in the user manual. After you've followed this simple workflow, then go
> > back to the more advanced stuff  in the tutorials and user manuals (like
> > cloning repositories and creating and merging branches).
> >
> > I created this exercise to try and model our workflow and what we wanted
> > to use git for = tracking a project with multiple files where the 
> > filebase
> > might change frequently from one version to the next.
> >
> > http://siliconmouth.wordpress.com/category/nerdy/
> >
> > look for December 27, 2008 or "git warmup"
> >
> >
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html 

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

[Jeff Whiteside]

> Thanks for your contrib. I'll pick these up for sure, but right now I'm
> despo to make some progress getting this confounded real-life project
> versioned.

np, i do understand totally.

> I've just made a commit I want to retract.

this is the purpose of git reset --soft/mixed/hard

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

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

with an uneasy conscience ;)

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

> BTW: sdf=Syntax Definition Formalism?

hahahaha, no, i was just typing/copypasting garbage, because my gmail
woudln't' get out of bold mode and forgot to delete it at the end.
haha.

On Mon, Dec 29, 2008 at 8:24 PM, Zorba <cr@altmore.co.uk> wrote:
> Hi Jeff,
>
> Thanks for your contrib. I'll pick these up for sure, but right now I'm
> despo to make some progress getting this confounded real-life project
> versioned.
>
> But where I'm stuck now touches on your post.
>
> I've just made a commit I want to retract.
>
> I have been using $ git reset --hard <version> as an escalator to ascend /
> descend the versions up and down
> 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.
>
> so when I reset to A, I've still got the ability to get to B or C again
>
> 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 ?
>
> 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).
>
> NB if you read my latest posts you will see why I chose the example I did
> for my "warm-up" as it closely models what I'm trying to do for real.
>
>
> BTW: sdf=Syntax Definition Formalism?
>
> "Jeff Whiteside" <jeff.m.whiteside@gmail.com> wrote in message
> news:3ab397d0812291505v77824e6fvdecebc80f38a5f89@mail.gmail.com...
>
> -"Rollback to each of the versions, starting with version A"
> this is bad.  you're saying rollback.  to others that have used scms,
> this will mean, "retrieve an older copy", but in git, this is DELETING
> all the versions after the version that you "rollback" to.  your blog
> post shouldn't discuss the git-reset --hard command at all, since
> you're rewriting history, which is dangerous.  afaik, most scms don't
> allow you to rewrite history.  to "rollback" to an older version you
> should use checkout the git-checkout command.  maybe the git reset
> -–hard HEAD is okay to include... but it won't be immediately obvious
> to new users why it does what it does... this nomenclature was likely
> not the best choice whenever it was made.
>
>
> gl with your gitting.
>
> whiteside
>
>
>
>
> u're talking sdf
>
>
>
>
> On Sat, Dec 27, 2008 at 5:29 PM, Zorba <cr@altmore.co.uk> wrote:
>>
>> tidied up the formatting, added a few more comments where needed, fixed
>> errors/lack of clarity
>>
>> "Zorba" <cr@altmore.co.uk> wrote in message
>> news:gj68a0$u56$3@ger.gmane.org...
>> > Here is a little exercise / tutorial / warm-up for someone starting out
>> > with Git. If you're anyting like me you may find the tutorials etc. on
>> > git.or.cz a bit daunting. I recommend you try this after reading the
>> > user
>> > manual but before tearing your hair out trying to follow all the
>> > examples
>> > in the user manual. After you've followed this simple workflow, then go
>> > back to the more advanced stuff  in the tutorials and user manuals (like
>> > cloning repositories and creating and merging branches).
>> >
>> > I created this exercise to try and model our workflow and what we wanted
>> > to use git for = tracking a project with multiple files where the
>> > filebase
>> > might change frequently from one version to the next.
>> >
>> > http://siliconmouth.wordpress.com/category/nerdy/
>> >
>> > look for December 27, 2008 or "git warmup"
>> >
>> >
>>
>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe git" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

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

[Sitaram Chamarty]

Hi Conor,

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

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

[Zorba]

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

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

[Zorba]

"Jeff Whiteside" <jeff.m.whiteside@gmail.com> wrote in message 
news:3ab397d0812291505v77824e6fvdecebc80f38a5f89@mail.gmail.com...
hi zorb,

you have done a great justice here to inadvertently explaining the
learning curve of git, through a few mistakes, especially for ppl
behind in their scm use.  i enjoyed reading your blog posts though, as
they remind me of myself, not long ago.

you have a couple of mistakes i think you should correct.

-"Imagine a project with 4 versions, made up of various configurations
of the three files."
this line implies that you have branches (the word configurations).
you should be focusing, at first, on a project that has a set number
of files, and the content merely changes.  ideally, you don't often
add and rm files across versions.  also, the project doesn't really
have 4 versions, like windows has 4 different versions of vista, the
project has 3 old versions and 1 new version.

** ok, I've changed "configurations" as its overloaded in the context of 
older SCMs.
Point taken about changing content not containers. However changing content 
is easier, and therefore less need for a tutorial
Also this write-up is basically a "note to self", that I've cleaned up in 
case someone else can find it useful, and the problem I was solving was a 
problem that involved containers changing.
I've explained the context for going the way of containers now in the 
write-up.
I've covered off your concern for ppl thinking we have 4x current versions 
(ie. branches) with "4 progressively more recent versions"

"Setup a git index in the project directory"
-this implies you're talking about the index.  you're not.  you're
talking about the repository.  either make it clear that the index is
an intermediary staging area, or ignore its existence and change all
git-add && git-commit references to git-commit -a references.  this
will ease the user of older scms into git.

** Don't forget they'll have read the tutorial and/or user-guide, and the 
concepts of an index and staging are fairly easy to pick up.
I'll keep it in, and make sure I refer to it as you suggest.

-"Rollback to each of the versions, starting with version A"
this is bad.  you're saying rollback.  to others that have used scms,
this will mean, "retrieve an older copy", but in git, this is DELETING
all the versions after the version that you "rollback" to.  your blog
post shouldn't discuss the git-reset --hard command at all, since
you're rewriting history, which is dangerous.  afaik, most scms don't
allow you to rewrite history.  to "rollback" to an older version you
should use checkout the git-checkout command.  maybe the git reset
-–hard HEAD is okay to include... but it won't be immediately obvious
to new users why it does what it does... this nomenclature was likely
not the best choice whenever it was made.

** have now promoted git-checkout as the way to review older versions
I've left git-reset in there, for my own notes as much as anything, but not 
suggesting it be used as some sort of cursor to move the HEAD up and down 
the branch

NB getting some funny results with git-checkout near the head of the branch
- will investigatge and report





u're talking sdf




On Sat, Dec 27, 2008 at 5:29 PM, Zorba <cr@altmore.co.uk> wrote:
>
> tidied up the formatting, added a few more comments where needed, fixed
> errors/lack of clarity
>
> "Zorba" <cr@altmore.co.uk> wrote in message
> news:gj68a0$u56$3@ger.gmane.org...
> > Here is a little exercise / tutorial / warm-up for someone starting out
> > with Git. If you're anyting like me you may find the tutorials etc. on
> > git.or.cz a bit daunting. I recommend you try this after reading the 
> > user
> > manual but before tearing your hair out trying to follow all the 
> > examples
> > in the user manual. After you've followed this simple workflow, then go
> > back to the more advanced stuff  in the tutorials and user manuals (like
> > cloning repositories and creating and merging branches).
> >
> > I created this exercise to try and model our workflow and what we wanted
> > to use git for = tracking a project with multiple files where the 
> > filebase
> > might change frequently from one version to the next.
> >
> > http://siliconmouth.wordpress.com/category/nerdy/
> >
> > look for December 27, 2008 or "git warmup"
> >
> >
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html 

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

[Zorba]

Ok, when I do

$ rm *.*
$ git checkout versionA .

I'm getting ABC.txt, AC.txt, BC.txt

which is wrong as only the first two files went into version A

Paradoxically

$ rm *.*
$ git reset --hard versionA

produces the desired result!

I picked up a few cases like this with git-checkout today. Usually a file or 
two gets copied into the working tree that shouldn't have been (and I'm 
clearing the working tree before each checkout, so its not "leftovers", its 
defo git-checkout doing it)

Its coming back to me now - when I was writing my "warm-up" I tried both 
git-checkout and git-reset, to do my "rollbacks" and git-checkout produced a 
few inconsistent results like above, so I decided to stick with git-reset 
(this was before I knew the dangers of git-reset of course!) for "safety".

Could it be that all the "vandalism" I've perpetrated to the history by 
resetting in a FORWARD direction could have corrupted the history somehow ?

Even so, you'd expect something vanilla like $ git checkout  not to be 
affected.

I'm gonna try the checkouts without doing any resetting beforehand (i.e. no 
messing with the history) to see if I can reproduce this.



"Zorba" <cr@altmore.co.uk> wrote in message 
news:gjdh0r$n3c$4@ger.gmane.org...

** have now promoted git-checkout as the way to review older versions
I've left git-reset in there, for my own notes as much as anything, but not
suggesting it be used as some sort of cursor to move the HEAD up and down
the branch

NB getting some funny results with git-checkout near the head of the branch
- will investigatge and report

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

[Zorba]

So I deleted the repo and the working tree, restarted the git bash (i.e. 
wiped the slate clean) and started my little warm up workflow again, getting 
as far as just created and tagged versionD.

So lets do some checking out

$ rm *.*
$ git checkout versionA .

gives ABC.txt, AC.txt = correct
however...

$ rm *.*
$ git checkout versionB .

gives ABC.txt, AC.txt, BC.txt
which is wrong

running gitk confirms that AC.txt should not be in versionB

!!!! 

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

[Jeff Whiteside]

> commit -a detects that files have been deleted, and takes them out of the index !
> could also have used $ git rm <specific files> and then $ git commit ..

hey! i like your changes! the post is pretty polished now.  the only
thing else i would change (srysry), is the above.  "-a detects that
files have been deleted"  -> heh, not true.  you don't need -a here;
it does something else.

okay i just recreated your repo and did the same thing.  with your
syntax "git checkout versionA ." i got the same result, and i'm not
sure why, but i think it was because of the detached head.

good news, use "git checkout versionA", not "git checkout versionA ."
(so, use it wihtout the dot), and you should be back in working order.

the other (good?)  news is that you probably _do_ want to be using git
reset --hard in your case, because you're trying to build up a history
from some project, so you do want to erase some faulty commits after
you bodge something or miss some files.

the bad news is that my opinion is that you should probably move on
with your life, because my own past tells me that you'll never
actually use those old project versions, hahah :p

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

[Daniel Barkalow]

On Sat, 27 Dec 2008, Zorba wrote:

> Here is a little exercise / tutorial / warm-up for someone starting out with 
> Git. If you're anyting like me you may find the tutorials etc. on git.or.cz 
> a bit daunting. I recommend you try this after reading the user manual but 
> before tearing your hair out trying to follow all the examples in the user 
> manual. After you've followed this simple workflow, then go back to the more 
> advanced stuff  in the tutorials and user manuals (like cloning repositories 
> and creating and merging branches).
>
> I created this exercise to try and model our workflow and what we wanted to 
> use git for = tracking a project with multiple files where the filebase 
> might change frequently from one version to the next.

One thing I find unrealistic about this example is that you've got BC.txt 
and C.txt when you're creating version A, and you've even copied them to 
the working directory. In real life, you'd almost certainly not create the 
files until you're preparing the version that includes them, at least if 
your history is version A, version B, version C. (Now, it's possible that 
your history is "create a bunch of files", "create version A without 
BC.txt and C.txt"; in parallel to version A, create version B without 
AC.txt and C.txt; but that's a different process entirely.)

I think the exercise would come out much more easily if you only created 
ABC.txt and AC.txt at the beginning, made version A, added BC.txt and 
removed AC.txt, made version B, created C.txt and recovered AC.txt, and 
made version C; this is, I believe, what would actually happen.

If you're having trouble with "git commit" putting you in a lousy editor, 
somebody probably needs to do better packaging. "git commit" (without the 
-m) should open up the best editor available on your computer, but it 
doesn't seem to have a good idea about your preferences for editors. Of 
course, part of the problem is people who don't like that editor rarely 
use the command line on Windows. Do you have a good editor for Windows? 
How have you specified it, if so?

	-Daniel
*This .sig left intentionally blank*

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

[Zorba]

** REPRODUCING Possible bug
rebooted PC, opened a new git bash, and started from scratch - see console 
output below

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

Welcome to Git (version 1.6.0.2-preview20080923)


Run 'git help git' to display the help index.
Run 'git help <command>' to display help for specific commands.

conorr@KINKLADZE /w/GITPLATFORM
$ mkdir swproj

conorr@KINKLADZE /w/GITPLATFORM
$ cd swproj

conorr@KINKLADZE /w/GITPLATFORM/swproj
$ cat > ABC.txt
ABC

conorr@KINKLADZE /w/GITPLATFORM/swproj
$ cat > BC.txt
BC

conorr@KINKLADZE /w/GITPLATFORM/swproj
$ cat > AC.txt
AC

conorr@KINKLADZE /w/GITPLATFORM/swproj
$ cat > C.txt
C

conorr@KINKLADZE /w/GITPLATFORM/swproj
$ ls
ABC.txt  AC.txt  BC.txt  C.txt

conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git init
Initialized empty Git repository in w:/GITPLATFORM/swproj/.git/

conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git add *a*.txt

conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git commit -m "version A"
Created initial commit 2b88490: version A
 2 files changed, 2 insertions(+), 0 deletions(-)
 create mode 100644 ABC.txt
 create mode 100644 AC.txt

conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git tag versionA 2b88

conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git rm AC.txt
rm 'AC.txt'

conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git add BC.txt

conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#       deleted:    AC.txt
#       new file:   BC.txt
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#       C.txt

conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git commit -m "version B"
Created commit c1e1cf8: version B
 2 files changed, 1 insertions(+), 1 deletions(-)
 delete mode 100644 AC.txt
 create mode 100644 BC.txt

conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git tag versionB c1e1

conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git add *c*.txt

conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git commit -m "version C"
Created commit 66c62fd: version C
 1 files changed, 1 insertions(+), 0 deletions(-)
 create mode 100644 C.txt

conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git tag versionC 66c6

conorr@KINKLADZE /w/GITPLATFORM/swproj
$ rm *.*

conorr@KINKLADZE /w/GITPLATFORM/swproj
$ ls

conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git commit -a -m "version D"
Created commit eee4a13: version D
 3 files changed, 0 insertions(+), 3 deletions(-)
 delete mode 100644 ABC.txt
 delete mode 100644 BC.txt
 delete mode 100644 C.txt

conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git tag versionD eee4

conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git status
# On branch master
nothing to commit (working directory clean)

conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git checkout versionA .

conorr@KINKLADZE /w/GITPLATFORM/swproj
$ ls
ABC.txt  AC.txt

conorr@KINKLADZE /w/GITPLATFORM/swproj
$ rm *.*

conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git checkout versionB .

conorr@KINKLADZE /w/GITPLATFORM/swproj
$ ls
ABC.txt  AC.txt  BC.txt

conorr@KINKLADZE /w/GITPLATFORM/swproj
$ rm *.*

conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git checkout versionC .

conorr@KINKLADZE /w/GITPLATFORM/swproj
$ ls
ABC.txt  AC.txt  BC.txt  C.txt

conorr@KINKLADZE /w/GITPLATFORM/swproj
$ rm *.*

conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git checkout versionD .

conorr@KINKLADZE /w/GITPLATFORM/swproj
$ ls
ABC.txt  AC.txt  BC.txt  C.txt

conorr@KINKLADZE /w/GITPLATFORM/swproj
$ gitk

conorr@KINKLADZE /w/GITPLATFORM/swproj
$ comment: gitk shows that versionA & C are correct, but B & D are wrong

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

[Zorba]

Thnks for reviewing !

"Jeff Whiteside" <jeff.m.whiteside@gmail.com> wrote in message 
news:3ab397d0812301035w3dcd872fkae9509629a0ed7de@mail.gmail.com...
>> commit -a detects that files have been deleted, and takes them out of the 
>> index !
>> could also have used $ git rm <specific files> and then $ git commit ..
>
> hey! i like your changes! the post is pretty polished now.  the only
> thing else i would change (srysry), is the above.  "-a detects that
> files have been deleted"  -> heh, not true.  you don't need -a here;
> it does something else.

** haven't had time to review this but from what you say it looks like I 
forgot to take this out

> okay i just recreated your repo and did the same thing.  with your
> syntax "git checkout versionA ." i got the same result, and i'm not
> sure why, but i think it was because of the detached head.

** at Yves' (demerphq) request I reproduced and posted the exact sequence of 
commands
this was from a reboot, going straight into git bash and running the warmup 
with NO git-resets at all

> good news, use "git checkout versionA", not "git checkout versionA ."
> (so, use it wihtout the dot), and you should be back in working order.

** yes but I don't get the files copied out into the tree which is all my 
little heart ever desired

> the other (good?)  news is that you probably _do_ want to be using git
> reset --hard in your case, because you're trying to build up a history
> from some project, so you do want to erase some faulty commits after
> you bodge something or miss some files.

** yes, now I know that git-reset is only for destruction, not navigation

> the bad news is that my opinion is that you should probably move on
> with your life, because my own past tells me that you'll never
> actually use those old project versions, hahah :p

** LOL, I have to admit I am enjoying this though, even if its driving me 
slightly potty - haha
I didn't write these early versions so I just wanna have them around to 
rollback to if I end up hacking the thing to bits.
But you're right - chances of using are slim - but you could say that about 
every version sitting in any given SCM repo.
Thats why we have SCM, and why we insure our cars etc etc. :-) 

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

[Boyd Stephen Smith Jr.]

[-- Attachment #1: Type: text/plain, Size: 1031 bytes --]

On Tuesday 2008 December 30 15:27:33 you wrote:
> conorr@KINKLADZE /w/GITPLATFORM/swproj
> $ git status
> # On branch master
> nothing to commit (working directory clean)
>
> conorr@KINKLADZE /w/GITPLATFORM/swproj
> $ git checkout versionA .
>
> conorr@KINKLADZE /w/GITPLATFORM/swproj
> $ ls
> ABC.txt  AC.txt
>
> conorr@KINKLADZE /w/GITPLATFORM/swproj
> $ rm *.*
>
> conorr@KINKLADZE /w/GITPLATFORM/swproj
> $ git checkout versionB .
>
> conorr@KINKLADZE /w/GITPLATFORM/swproj
> $ ls
> ABC.txt  AC.txt  BC.txt

Not a bug.  git checkout <commit> <paths> does not delete files by design.  
Try using "git checkout versionB" instead (no paths specified), and it will 
properly remove AC.txt from your working tree as well as warning you 
that "You're Doing It Wrong" (tm).
-- 
Boyd Stephen Smith Jr.                     ,= ,-_-. =. 
bss@iguanasuicide.net                     ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy           `-'(. .)`-' 
http://iguanasuicide.net/                      \_/     

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

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

[Jeff Whiteside]

>> good news, use "git checkout versionA", not "git checkout versionA ."
>> (so, use it wihtout the dot), and you should be back in working order.
>
> ** yes but I don't get the files copied out into the tree which is all my
> little heart ever desired

you dont "get the files copied out into the tree"...  i have zero idea
what that means wihtout punctuation and context, but i'm pretty sure
that you want to do a "git checkout versionA", not  "git checkout
versionA .".  if i'm wrong, then maybe try a git clean?

> But you're right - chances of using are slim - but you could say that about
> every version sitting in any given SCM repo.
> Thats why we have SCM, and why we insure our cars etc etc. :-)

i punish myself for saying what i did.  shame on me.  you're totally right.

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

[Boyd Stephen Smith Jr.]

[-- Attachment #1: Type: text/plain, Size: 4075 bytes --]

On Tuesday 2008 December 30 15:49:22 Boyd Stephen Smith Jr. wrote:
> On Tuesday 2008 December 30 15:27:33 you wrote:
> > conorr@KINKLADZE /w/GITPLATFORM/swproj
> > $ git status
> > # On branch master
> > nothing to commit (working directory clean)
> >
> > conorr@KINKLADZE /w/GITPLATFORM/swproj
> > $ git checkout versionA .
> >
> > conorr@KINKLADZE /w/GITPLATFORM/swproj
> > $ ls
> > ABC.txt  AC.txt
> >
> > conorr@KINKLADZE /w/GITPLATFORM/swproj
> > $ rm *.*
> >
> > conorr@KINKLADZE /w/GITPLATFORM/swproj
> > $ git checkout versionB .
> >
> > conorr@KINKLADZE /w/GITPLATFORM/swproj
> > $ ls
> > ABC.txt  AC.txt  BC.txt
>
> Not a bug.  git checkout <commit> <paths> does not delete files by design.
> Try using "git checkout versionB" instead (no paths specified), and it will
> properly remove AC.txt from your working tree as well as warning you
> that "You're Doing It Wrong" (tm).

This may be what you want:
(commands)
mkdir test && cd test && git init &&

echo 'ABC' > ABC.txt && echo 'AC' > AC.txt &&
echo 'BC' > BC.txt && echo 'C' > C.txt &&

find -name '*C*' -print0 | xargs -r0 -- git add -- &&
git commit -m '"C" files.' && git branch versionC master &&

git checkout -b versionA master &&
find -type f -not -wholename '*.git*' -not -name '*A*' -print0 | \
	xargs -r0 -- git rm -- &&
git commit -m 'Removed non-"A" files.' &&

git checkout -b versionB &&
find -type f -not -wholename '*.git*' -not -name '*B*' -print0 | \
	xargs -r0 -- git rm -- &&
git commit -m 'Removed non-"B" files.' &&

git checkout -b versionD master &&
find -type f -not -wholename '*.git*' -not -name '*D*' -print0 | \
	xargs -r0 -- git rm -- && git commit -m 'Removed non-"D" files.' &&

git checkout master && git branch -v --abbrev=4 && ls -l &&
git checkout versionA && ls -l &&
git checkout versionB && ls -l &&
git checkout versionC && ls -l &&
git checkout versionD && ls -l

(output)
/home/bss/test
Initialized empty Git repository in /home/bss/test/.git/
Created initial commit 8dbf3a1: All files.
 4 files changed, 4 insertions(+), 0 deletions(-)
 create mode 100644 ABC.txt
 create mode 100644 AC.txt
 create mode 100644 BC.txt
 create mode 100644 C.txt
Switched to a new branch "versionA"
rm 'BC.txt'
rm 'C.txt'
Created commit a06e10c: Removed non-"A" files.
 2 files changed, 0 insertions(+), 2 deletions(-)
 delete mode 100644 BC.txt
 delete mode 100644 C.txt
Switched to a new branch "versionB"
rm 'AC.txt'
Created commit 2029ca2: Removed non-"B" files.
 1 files changed, 0 insertions(+), 1 deletions(-)
 delete mode 100644 AC.txt
Switched to a new branch "versionD"
rm 'ABC.txt'
rm 'AC.txt'
rm 'BC.txt'
rm 'C.txt'
Created commit 1793ba0: Removed non-"D" files.
 4 files changed, 0 insertions(+), 4 deletions(-)
 delete mode 100644 ABC.txt
 delete mode 100644 AC.txt
 delete mode 100644 BC.txt
 delete mode 100644 C.txt
Switched to branch "master"
* master   8dbf "C" files.
  versionA a06e Removed non-"A" files.
  versionB 2029 Removed non-"B" files.
  versionC 8dbf "C" files.
  versionD 1793 Removed non-"D" files.
total 16
-rw-r--r-- 1 bss users 4 2008-12-30 16:10 ABC.txt
-rw-r--r-- 1 bss users 3 2008-12-30 16:10 AC.txt
-rw-r--r-- 1 bss users 3 2008-12-30 16:10 BC.txt
-rw-r--r-- 1 bss users 2 2008-12-30 16:10 C.txt
Switched to branch "versionA"
total 8
-rw-r--r-- 1 bss users 4 2008-12-30 16:10 ABC.txt
-rw-r--r-- 1 bss users 3 2008-12-30 16:10 AC.txt
Switched to branch "versionB"
total 4
-rw-r--r-- 1 bss users 4 2008-12-30 16:10 ABC.txt
Switched to branch "versionC"
total 16
-rw-r--r-- 1 bss users 4 2008-12-30 16:10 ABC.txt
-rw-r--r-- 1 bss users 3 2008-12-30 16:10 AC.txt
-rw-r--r-- 1 bss users 3 2008-12-30 16:10 BC.txt
-rw-r--r-- 1 bss users 2 2008-12-30 16:10 C.txt
Switched to branch "versionD"
total 0
-- 
Boyd Stephen Smith Jr.                     ,= ,-_-. =. 
bss@iguanasuicide.net                     ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy           `-'(. .)`-' 
http://iguanasuicide.net/                      \_/     

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

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

[Boyd Stephen Smith Jr.]

[-- Attachment #1: Type: text/plain, Size: 544 bytes --]

On Tuesday 2008 December 30 16:17:11 Boyd Stephen Smith Jr. wrote:
> git checkout -b versionB &&

Should be:

git checkout -b versionB master &&

to match the other section and fix this part of the output:
> Switched to branch "versionB"
> total 4
> -rw-r--r-- 1 bss users 4 2008-12-30 16:10 ABC.txt
-- 
Boyd Stephen Smith Jr.                     ,= ,-_-. =. 
bss@iguanasuicide.net                     ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy           `-'(. .)`-' 
http://iguanasuicide.net/                      \_/     

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

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

[Daniel Barkalow]

On Tue, 30 Dec 2008, Zorba wrote:

> > good news, use "git checkout versionA", not "git checkout versionA ."
> > (so, use it wihtout the dot), and you should be back in working order.
> 
> ** yes but I don't get the files copied out into the tree which is all my 
> little heart ever desired

So in order for this to make sense, you're going to need to know a little 
tiny bit about branches (which, fortunately, is trivial compared to 
branches in most SCMs). In git, a branch is a mutable pointer to a commit, 
which is the latest commit on the branch (all of the earlier commits on 
the branch are linked off of the latest one; each commit points to the one 
before). By default, you have a branch called "master", and that's the 
branch that your series of commands builds up. Now, at any given time, you 
can have a "current branch" (a.k.a. HEAD), which is the branch that you'd 
put a new commit on if you made one. "master" is your current branch while 
you're building up that history.

When you want to navigate the history, however, you want to leave all of 
the branches alone and take your working directory into the history. This 
is known as being on "(no branch)" or, as Zippy would say, having a 
"detached HEAD". This way you leave the "master" branch pointing to 
versionD, which is, after all, the latest commit, while you get yourself 
an old version. You can do this with:

$ git checkout versionA

because you've made a tag for it. In order to get back to developing (as 
opposed to looking at history), you use:

$ git checkout master

(because "master" is your branch, while "versionA" is a tag).

If you're on master, either after checking it out explicitly or before 
you've used checkout at all, doing:

$ git checkout versionA .

with *not* switch you away from the current branch, but will get the 
contents of "." from versionA into your index and working directory, and 
it doesn't remove things that you have currently.

> ** LOL, I have to admit I am enjoying this though, even if its driving me 
> slightly potty - haha
> I didn't write these early versions so I just wanna have them around to 
> rollback to if I end up hacking the thing to bits.
> But you're right - chances of using are slim - but you could say that about 
> every version sitting in any given SCM repo.
> Thats why we have SCM, and why we insure our cars etc etc. :-) 

Even if you never rolling back to it, it's useful for figuring out what 
you did when.

	-Daniel
*This .sig left intentionally blank*

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

[Zorba]

> So in order for this to make sense, you're going to need to know a little
> tiny bit about branches

** (sigh) At some level I knew I'd have to face up to this... - ok lets do 
it

(which, fortunately, is trivial compared to
> branches in most SCMs). In git, a branch is a mutable pointer to a commit,
> which is the latest commit on the branch (all of the earlier commits on
> the branch are linked off of the latest one; each commit points to the one
> before). By default, you have a branch called "master", and that's the
> branch that your series of commands builds up. Now, at any given time, you
> can have a "current branch" (a.k.a. HEAD), which is the branch that you'd
> put a new commit on if you made one. "master" is your current branch while
> you're building up that history.

> When you want to navigate the history, however, you want to leave all of
> the branches alone and take your working directory into the history. This
> is known as being on "(no branch)" or, as Zippy would say, having a
> "detached HEAD". This way you leave the "master" branch pointing to
> versionD, which is, after all, the latest commit, while you get yourself
> an old version. You can do this with:

> $ git checkout versionA
>
> because you've made a tag for it. In order to get back to developing (as
> opposed to looking at history), you use:
>
> $ git checkout master
>
> (because "master" is your branch, while "versionA" is a tag).
>
> If you're on master, either after checking it out explicitly or before
> you've used checkout at all, doing:
>
> $ git checkout versionA .
>
> with *not* switch you away from the current branch, but will get the
> contents of "." from versionA into your index and working directory, and
> it doesn't remove things that you have currently.

** ok, thanks for explaining - one little dot and my HEAD don't get a 
holiday !

Now, lets say we checkout versionB. I don't just want to be pointing at 
versionB in the repo, I want an exact copy (no more, no less) of all the 
files in version B, to be placed in the working tree. Currently this is not 
happening reliably.

Is that too much to ask ?

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

[Sitaram Chamarty]

On 2008-12-30, Zorba <cr@altmore.co.uk> wrote:
> ** REPRODUCING Possible bug

[long script using "git checkout tag ." removed...]

Conor,

As Stephen said, you're using an extra "." which changes the
meaning completely.

In addition, the weird behaviour you see, where AC.txt
appears to have sneaked in when you do a "git checkout
versionB .", even though versionB does not have that file,
is also correct -- read the second para of the DESCRIPTION
section in "git help checkout", and note the phrase "update
the index ... before updating the working tree".

In other words, the special form of git checkout you used is
updating not only the working tree but also the index.  So
when you checked out versionA in this manner, AC.txt got
into the index (as well as the working tree).

Your subsequent "rm *.*" only deeltes those files from the
working tree; they're still in the index.  To see this, run
"git ls-files -s" just after each "rm *.*".

You can also get the results you *want* to get by running a
"git reset --hard" instead of "rm *.*", since your top
commit in the current branch (which is what this would
default to) has no files in it anyway.

Happy New Year from India to Northern Ireland and everyone
else in the world :-)