1. Stefan Saasen
  2. git


J. Bruce Fields  committed 82c8bf2

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>

  • Participants
  • Parent commits 4db75b7
  • Branches master

Comments (0)

Files changed (2)

File Documentation/howto/make-dist.txt

  • Ignore whitespace
-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

File Documentation/user-manual.txt

View file
  • Ignore whitespace
 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.
+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
+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:
+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