Re: Yet another Git tutorial

[Junio C Hamano <gitster@pobox.com>]

Page #5; after teaching "cat-file -t" it would make sense to teach
"cat-file blob" to view what was stored.

Page #5; likewise, "cat-file -t HEAD" to inspect and "cat-file commit
HEAD" to show its contents would be a much better "bottom-up" way to show
how the pieces fit together, instead of doing "show --pretty=format:%T".

Page #6; "HEAD tag"???

Page #6; s/my system/my repository/, as you use that word a few lines
later.

You use "id", "hash id", "hash number", "hash" etc. and have your readers
guess that you are talking about the same thing.  It would be better to
use a single word consistently (the official name of this number is the
"object name").

s/index cache/the index/.

s/tree owns blob/tree holds blob/, perhaps.

Page #9; before this point, your tree owned blobs but now suddenly it
references trees and blobs.  There should be a mention of this recursive
construction of a tree earlier soon after you introduced the tree
objects. 

Page #11: s/name:file/name:path/; notice that it can be non-files such as
symlinks and trees.

Page #12: s/name{tree}/name^{tree}/.

Page #12: name1..name2; "between name1 and name2, inclusive"?  This
excludes the left end.  "Everything reachable from name2 except the ones
reachable from name1".

Page #12: name1...name2.  This is a symmetric difference for "git log"
family of commands (iow when you talk about set of commits) which means
"Reachable either from name1 or name2 but not from both".  When used with
"git diff" to name two endpoints, this means what you described
(differences since the common ancestor of these two to name2).

Page #12: master..; it would also be useful to mention ..other here.

Page #17: The example makes me wonder what you did exactly to commit I.
It would contain roughly an equivalent of squashed B+C together, which may
or may not be what you want.

Page #18: There is no "two different things" reason behind the name.  It
was originally called "directory cache" and then renamed to "the index".
These days, most of the time we use these two words interchangeably, but
when we are picky, index tends to mean the file on the filesystem
(i.e. $GIT_INDEX_FILE aka $GIT_DIR/index) while cache tends to mean the
in-core structure (i.e. the_index.cache aka active_cache).

Page #22: "git reset --mixed" will remove blobs???  You surely did not
mean that.  It just reverts the staged contents to that of the HEAD (or
whichever commit you named and moved your HEAD to).

Page #24: saves your work in the stash "for the current branch"???  There
is no per-branch stash.  You can stash, switch branches and then apply the
stashed change to the other branch.