On 9/29/05, Petr Baudis <[email protected]> wrote:
> Hello,
>
> I think Pavel Machek had some short git HOWTO as well, so I'm Cc'ing him.
>
Ok, thanks. I was not aware of that.
> 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.
>
The reason for this document is to cater to the people who have a
kernel source tree available, know the kernel is managed with git, but
don't know how to obtain it. Such people (myself included) probably
take a quick look in linux-<version>/Documentation/ for a document
telling them how to get and install git. This document is written to
serve those people.
> 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
I'm Cc'ing you exactely because I thought you would have some valuable input :)
> 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.
>
something like that would probably make sense, yes.
> > +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'.
>
Whoops.
> > +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
> > +filename).
>
> 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.
>
Hmm, yes, you are probably right. I should recommend the latest
release and just provide a small note on how to get the latest
snapshot. Thanks.
> ...
> > +At this point you should have git installed and available in your PATH.
>
> Perhaps you might rather want to extend GIT's INSTALL file?
>
I can provide a patch for that if you like, sure.
> > +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/.
>
Hmm, right, my bad.
> 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"
This is supposed to tell people how to get and install git for *the
very first time*, so this would be the initial clone.
> 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.
>
I think the best thing is just to drop that second bit.
> > +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.
>
I'm not a native english speaker either, so you may very well be right
- I honestly don't know :)
> > +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
> Documentation/BUG-HUNTING file.
>
Not a bad suggestion - anyone else have an oppinion on that?
Thank you for your constructive feedback. Much appreciated.
--
Jesper Juhl <[email protected]>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
-
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]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |