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

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" 

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

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:

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:

np, i do understand totally.

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

you should probably be using git checkout for this

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.

with an uneasy conscience ;)

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

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.

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:

you should probably be using git checkout for this

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

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

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

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.

Hi Conor,

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

if this is true...  (call this case 1)

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

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

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

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

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

!!!! 

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

Thnks for reviewing !

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

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

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

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

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

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

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?

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

On Tue, 30 Dec 2008, Zorba wrote:

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.

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

	-Daniel
*This .sig left intentionally blank*

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

(which, fortunately, is trivial compared to

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

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

On Tuesday 2008 December 30 15:27:33 you wrote:

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

On Tuesday 2008 December 30 15:49:22 Boyd Stephen Smith Jr. wrote:

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

On Tuesday 2008 December 30 16:17:11 Boyd Stephen Smith Jr. wrote:

Should be:

git checkout -b versionB master &&

to match the other section and fix this part of the output:

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

[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 :-)

On Sat, 27 Dec 2008, Zorba wrote:

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*