I think Pavel Machek had some short git HOWTO as well, so I'm Cc'ing him.
In general, I think it's not a good idea to just duplicate GIT
documentation in the kernel tree. If you think the GIT documentation is
insufficient or is missing some "quick start" document, it'd be more
reasonable to submit patches for GIT, but I'd keep kernel's GIT
documentation to kernel-specific usage and tips'n'tricks.
Dear diary, on Thu, Sep 29, 2005 at 03:05:01AM CEST, I got a letter
where Jesper Juhl <[email protected]> told me that...
> --- /dev/null 2005-09-28 20:05:57.000000000 +0200
> +++ linux-2.6.14-rc2-git3/Documentation/get-and-install-git.txt 2005-09-29 02:57:59.000000000 +0200
> @@ -0,0 +1,130 @@
> + Getting and installing `git` and pulling your first tree
> + --------------------------------------------------------
> + (Writen by Jesper Juhl, September 2005)
> +This document describes how to obtain and install the `git` tool used (among
> +other things) to manage the Linux kernel source tree. It also shows you how
> +to use git to pull down your first copy of the vanilla Linux kernel source
> +(current git head version).
Since you're cc'ing me, you'll get a shameless plug. ;-) What about
some decent short notice like:
Note that you might prefer to use one of the simpler user interfaces
available for GIT, e.g. the Cogito layer or StGIT patch manager. See
the GIT homepage for details.
> +Those who already have an older version of git can grab a newer version with
> + it clone http://www.kernel.org/pub/scm/git/git.git LOCALDIR
Missing leading 'g'.
> +To obtain the latest git source snapshot go to this URL:
> + http://www.codemonkey.org.uk/projects/git-snapshots/git/
> +and download the latest version (at the time of this writing the exact filename
> +is git-2005-09-29.tar.gz, but a symlink called git-latest.tar.gz is also
> +provided that will always pull the latest git source regardless of its actual
I think recommending the latest development snapshot instead of the
latest release is a really bad idea if you don't have some really
compelling reason to do so. The snapshot can be variously broken and
buggy, while a release gives you some stable reference point and path
from it you can follow.
> +At this point you should have git installed and available in your PATH.
Perhaps you might rather want to extend GIT's INSTALL file?
> +Now it's time to download your first kernel source tree. To do that you should
> +first change into the directory where you want to store the kernel source in a
> +subdir. I'll assume you want to keep kernel source in ~/linux-kernel, so do
> +this :
> + $ mkdir ~/linux-kernel ; cd ~/linux-kernel
> +Now let's use git to download the latest git HEAD (the current head of Linus'
> +development tree). Execute these commands to do this :
> + $ git clone \
> + rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git \
> + linux-2.6
> + $ cd linux-2.6
> + $ rsync -a --verbose --stats --progress \
> + rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/ \
> + .git/
Why the second rsync command? If you are after tags and other heads, you
can run it just on .git/refs/.
But actually, it is very dangerous. Never ever run it later than right
after the initial clone (ignore what the "Kernel Hackers' Guide to git"
tells you!). If you did any local commits, it will likely trash them,
and if you didn't, it will probably completely confuse the tools which
care about updating your working tree with new changes.
> +When the download finishes you'll have a brand sparkling new git HEAD linux
> +kernel source tree in ~/linux-kernel/linux-2.6
[Nitpick] I'm not a native English speaker, but I think "brand new
sparkling" is more right.
> +If you want to do a git bisection search to find what patch caused a problem,
> +please see the Documentation/git-bisect.txt document in the git source tree.
> +You may also want to read and/or use Documentation/git-bisect-script.txt
This notice would be quite useful in the rather antique
Petr "Pasky" Baudis
VI has two modes: the one in which it beeps and the one in which
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Video 4 Linux]
[Linux for the blind]