user-manual: move howto/make-dist.txt into user manual

There seems to be a perception that the howto's are bit-rotting a
little.  The manual might be a more visible location for some of them,
and make-dist.txt seems like a good candidate to include as an example
in the manual.

For now, incorporate much of it verbatim.  Later we may want to update
the example a bit.

Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
This commit is contained in:
J. Bruce Fields 2007-05-13 00:14:40 -04:00
Родитель 4db75b70d1
Коммит 82c8bf28f8
2 изменённых файлов: 42 добавлений и 52 удалений

Просмотреть файл

@ -1,52 +0,0 @@
Date: Fri, 12 Aug 2005 22:39:48 -0700 (PDT)
From: Linus Torvalds <torvalds@osdl.org>
To: Dave Jones <davej@redhat.com>
cc: git@vger.kernel.org
Subject: Re: Fwd: Re: git checkout -f branch doesn't remove extra files
Abstract: In this article, Linus talks about building a tarball,
incremental patch, and ChangeLog, given a base release and two
rc releases, following the convention of giving the patch from
the base release and the latest rc, with ChangeLog between the
last rc and the latest rc.
On Sat, 13 Aug 2005, Dave Jones wrote:
>
> > Git actually has a _lot_ of nifty tools. I didn't realize that people
> > didn't know about such basic stuff as "git-tar-tree" and "git-ls-files".
>
> Maybe its because things are moving so fast :) Or maybe I just wasn't
> paying attention on that day. (I even read the git changes via RSS,
> so I should have no excuse).
Well, git-tar-tree has been there since late April - it's actually one of
those really early commands. I'm pretty sure the RSS feed came later ;)
I use it all the time in doing releases, it's a lot faster than creating a
tar tree by reading the filesystem (even if you don't have to check things
out). A hidden pearl.
This is my crappy "release-script":
[torvalds@g5 ~]$ cat bin/release-script
#!/bin/sh
stable="$1"
last="$2"
new="$3"
echo "# git-tag v$new"
echo "git-tar-tree v$new linux-$new | gzip -9 > ../linux-$new.tar.gz"
echo "git-diff-tree -p v$stable v$new | gzip -9 > ../patch-$new.gz"
echo "git-rev-list --pretty v$new ^v$last > ../ChangeLog-$new"
echo "git-rev-list --pretty=short v$new ^v$last | git-shortlog > ../ShortLog"
echo "git-diff-tree -p v$last v$new | git-apply --stat > ../diffstat-$new"
and when I want to do a new kernel release I literally first tag it, and
then do
release-script 2.6.12 2.6.13-rc6 2.6.13-rc7
and check that things look sane, and then just cut-and-paste the commands.
Yeah, it's stupid.
Linus

Просмотреть файл

@ -808,6 +808,48 @@ available
Which shows that e05db0fd is reachable from itself, from v1.5.0-rc1, and
from v1.5.0-rc2, but not from v1.5.0-rc0.
[[making-a-release]]
Creating a changelog and tarball for a software release
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The gitlink:git-archive[1] command can create a tar or zip archive from
any version of a project; for example:
-------------------------------------------------
$ git archive --format=tar --prefix=project/ HEAD | gzip >latest.tar.gz
-------------------------------------------------
will use HEAD to produce a tar archive in which each filename is
preceded by "prefix/".
If you're releasing a new version of a software project, you may want
to simultaneously make a changelog to include in the release
announcement.
Linus Torvalds, for example, makes new kernel releases by tagging them,
then running:
-------------------------------------------------
$ release-script 2.6.12 2.6.13-rc6 2.6.13-rc7
-------------------------------------------------
where release-script is a shell script that looks like:
-------------------------------------------------
#!/bin/sh
stable="$1"
last="$2"
new="$3"
echo "# git tag v$new"
echo "git archive --prefix=linux-$new/ v$new | gzip -9 > ../linux-$new.tar.gz"
echo "git diff v$stable v$new | gzip -9 > ../patch-$new.gz"
echo "git log --no-merges v$new ^v$last > ../ChangeLog-$new"
echo "git shortlog --no-merges v$new ^v$last > ../ShortLog"
echo "git diff --stat --summary -M v$last v$new > ../diffstat-$new"
-------------------------------------------------
and then he just cut-and-pastes the output commands after verifying that
they look OK.
[[Developing-with-git]]
Developing with git