Re: Yet another Git tutorial

[Dmitry Potapov <dpotapov@gmail.com>]

On Mon, Apr 28, 2008 at 02:39:46AM -0400, John Wiegley wrote:
> I published another tutorial on Git today, this one describing the  
> system from a "bottom up" perspective.  I know it's been written about  
> this way before, but I was aiming at a bit more thoroughness, and a  
> paced introduction to the basics.
> 
> There's a link to the PDF is in the following blog post:
> 
>   http://www.newartisans.com/blog_files/git.from.bottom.up.php

In addition to what was mentioned before me:

On page 6, instead of `git show --pretty=format:%T HEAD | head -1`, it
is better to use `git log -1 --pretty=format:'%T' HEAD`. In general,
`git show <commit-object>` is `git log -1 -p <commit-object>`, and
you do not need diff here.

On page 7:
> This blob doesn't live in a tree yet, nor are there any commits.

It is probably nit-picking, but blobs never live in trees. They may
only be referenced by trees, while they always reside in 'objects'.
At this point, the blob is already placed into 'objects', but it is
not referenced by any tree, but only by index. So if you decide not
to commit this file then this blob will become dangling.

On page 10:
> circles are commit objects, and all but the first link to one or more
> parent commits, thus forming a "history"

Though typically there is only one commit object in Git repository
without a parent, it could be more than one.

> every commit holds a tree, and every tree must have at least one blob
> in its leaves

If there is no files in the current commit then the commit object
will reference to an empty tree, i.e. without any blob in it.


On page 12:
> name1..name2
> 
> The syntax to the le refers to all the commits between name1
> and name2, inclusive.

Actually, inclusive name2 but excluding name1. IMHO, it is better to
describe it as:
`name1..name2` is a short-hand for `^name1 name2`, which is equivalent
to `name2 --not name1`, i.e. all commits in name1 excluding those that
are part of name2.

> name1...name2
> 
> For example, if you had two development branches, "foo" and
> "bar", you could show all the commits which had happened on
> bar since their common ancestor using this command:

Not true. It shows all commits on both "foo" and "bar" that's happened
since their common ancestors. In other words, `name1...name2` is
equivalent to `name1 name2 --not $(git-merge-base --all name1 name2)`.
The '--all' flag means to consider their all ancestors, not just first
one.


BTW, maybe it would be useful to mention `git log -S<string>` somewhere
as a better alternative to `git blame`, because people with CVS/SVN
background tend to abuse `git blame` while `git log -S` is usually more
convenient and more efficient.


Dmitry