Goal #1: Put my little project into a git repo.

Using this tutorial:
http://kernel.org/pub/software/scm/git-core/docs/v1.2.6/tutorial.html

To package this code:
http://mspevack.fedorapeople.org/ekg/code/

####################################################################
# 
#    Part I.  Initial Repo Creation.
#    Instructions follow from the tutorial.
#    My comments in standard comment style.
#
####################################################################

Importing a new project

Assume you have a tarball project.tar.gz with your initial work. You can place it under git revision control as follows.

$ tar xzf project.tar.gz
$ cd project
$ git init-db

Git will reply

defaulting to local storage area

# Nope... actually responded with this:
# Initialized empty Git repository in /$PATH/EKG/EKG-OLD-SCHOOL/.git/
#
# Maybe this is from an old version.  The mismatch of expectations is
# confusing... is it meaningful?  Am I already off the path?

You've now initialized the working directory—you may notice a new directory created, named ".git". Tell git that you want it to track every file under the current directory with

$ git add .

# Okay, I guess that worked.  I got no feedback at all, just a return to
# the command prompt.

Finally,

$ git commit -a

will prompt you for a commit message, then record the current state of all the files to the repository.

# OK, that looked good.  Got some actual feedback:
# [gdk@localhost EKG-OLD-SCHOOL]$ git commit -a
# [master (root-commit) a2d09ed] Initial commit of this codebase.
#  5 files changed, 327 insertions(+), 0 deletions(-)
# create mode 100755 CRUNCH-ytd.pl
# create mode 100755 GET-all-lists.sh
# create mode 100755 PARSE-fedora.pl
# create mode 100755 PARSE-rh.pl
# create mode 100644 README


####################################################################
# 
#    Part II.  Modifying and committing code.
#    Instructions follow from the tutorial.
#
####################################################################

Try modifying some files, then run

$ git diff

# Good, produces a standard looking diff.

to review your changes. When you're done,

$ git commit -a

will again prompt your for a message describing the change, and then record the new versions of the modified files.

# Yes, very good:
#
# [gdk@localhost EKG-OLD-SCHOOL]$ git commit -a
# [master 7077faa] Updating documentation
# 1 files changed, 6 insertions(+), 2 deletions(-)

A note on commit messages: Though not required, it's a good idea to begin the commit message with a single short (less than 50 character) line summarizing the change, followed by a blank line and then a more thorough description. Tools that turn commits into email, for example, use the first line on the Subject line and the rest of the commit in the body.

# A good tip for developers, but useful enough for the student to be
# included in the top-level tutorial?  I don't know.


####################################################################
# 
#    Part III.  Adding new files.
#    Instructions follow from the tutorial.
#
####################################################################

To add a new file, first create the file, then

$ git add path/to/new/file

# OK, done, although again, no feedback:
#
# [gdk@localhost EKG-OLD-SCHOOL]$ git add COPYING 
# [gdk@localhost EKG-OLD-SCHOOL]$ 

then commit as usual. No special command is required when removing a file; just remove it, then commit.

# So this means that "git commit -a" is "commit as usual"?  What's the -a
# switch mean?  Maybe this could be an exercise -- blog about the -a switch
# and when it's needed.
#
# So assuming that "git commit -a" is what is meant:
#
# [gdk@localhost EKG-OLD-SCHOOL]$ git commit -a
# [master 54d053d] Now licensed under the WTFPL
#  1 files changed, 14 insertions(+), 0 deletions(-)
#  create mode 100644 COPYING
 
At any point you can view the history of your changes using

$ git whatchanged

# ...which throws you into a code-browsing thing that looks like "less".
# Great if you've ever seen less before, confusing otherwise.  Might also
# be worth putting some sample output out there.

If you also want to see complete diffs at each step, use

$ git whatchanged -p

# OK, what does the -p switch mean?  Ah, it means showing the contents of
# the files, rather than the diff statements themselves.  This could be
# made much clearer.
#
# That's it for the first section of the tutorial.  Pretty useful in 
# general; a few tweaks would be helpful; there are clearly some potential
# break points for exercises here.