When building from source, the easy way to get the man pages is to download
the appropriate git-manpages tarball (at the same URL as the source code)
and extract it into /usr/share/man. You want the man pages because "git help"
displays them.

You start with an up-to-the-minute copy of the linux kernel source, which
you can use just like an extracted tarball (ignoring the extra files in the
".git" directory). If you're interested in history from the bitkeeper days
(before 2.6.12-rc2), that's stored in a seperate repository,
"git://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git".
(Here is a list of all git repositories hosted
on kernel.org.)

If you forget the URL a git repository came from, it's in the file
".git/FETCH_HEAD". Normally you shouldn't need to care, since git remembers
it.

Note that unlike Mercurial, the URLs git uses aren't the same ones you
find repositories at on the web. You have to translate them. For example,
the "stable-queue" repository at which bugfix-only patches for fourth level
dot release of the linux kernel queue up before going in is on the web at
http://git.kernel.org/?p=linux/kernel/git/stable/stable-queue.git.
In this case, the corresponding git repository would be cloned with:

Here is a real git bisect run I did on the qemu
git repository (git://git.kernel.dk/data/git/qemu) to figure out why
the PowerPC Linux kernel I'd built was hanging during IDE controller
intiialization under the current development version of qemu-system-ppc
(but not under older versions).

git clone git://blah/blah/blah localdir - Download a repository
from the web into "localdir". Linus's current repository is at
"git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git",
the old history from the bitkeeper days (before 2.6.12-rc2) is at
"git://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git", and
there are lots of other trees hosted on
kernel.org and elsewhere.

git pull - Freshen up your local copy of the repository, downloading
and merging all of Linus's changes since last time you did this. In addition
to appending lots of commits to your repository in the .git directory, this
also updates the snapshot of the files (if it isn't already pointing into
the past).

git log - List the changes recorded in your repository, starting with
the most recent and working back. Note: the big hex numbers are unique
identifiers (sha1sum) for each commit. If you want to specify a commit, you
only need a unique prefix (generally the first four digits is enough).

git tag -l - Show all the tagged releases. These human-readable
names can be used as synonyms for the appropriate commit identifier when
doing things like checkout and diff. (Note, the special tag "master"
points to the most recent commit.)

git checkout -f; git clean -d - reset your snapshot to the most recent
commit. The "checkout" command updates your snapshot to a specific version
(defaulting to the tip of the current branch). The -f argument says to back
out any local changes you've made to the files, and "clean -d" says to
delete any extra files in the snapshot that aren't checked into the
repository.

git diff - Show differences between two commits, such as
"git diff v2.6.20 v2.6.21". You can also specify specific files you're
interested in, ala "git diff v2.6.20 v2.6.21 README init/main.c". If you
specify one version it'll compare your working directory against that version,
and if you specify no versions it'll compare the version you checked out
against your working directory. Anything that isn't recognized as the start of
a commit indentifying sha1sum, or a tagged release, is assumed to be a filename.
If this causes problems, you can add "--" to the command line to explicitly
specify that arguments before that (if any) are version identifiers and all the
arguments after that are filenames. Add "--find-copies-harder" to detect
renames.