Re: Yet another Git tutorial

From: Dmitry Potapov <dpotapov@gmail.com>
Date: Apr 28, 2008, 22:27 UTC
Message-ID: <20080428222717.GA6160@dpotapov.dyndns.org>
In-Reply-To: <2D3D2E55-74C7-4373-BC22-9CF4C26C197D@newartisans.com>

On Mon, Apr 28, 2008 at 02:39:46AM -0400, John Wiegley wrote:

Show 8 quoted lines

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

Show 5 quoted lines

> 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