mention git vs. bootstrapping

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I'm committing this, based on some recent conversation on the libtool
lists about their conversion to git and its impact on version stamps.  As
I understand things, it should be possible to bootstrap autoconf from the
CVS mirrors, but the version stamp will not be generated in that case, so
the resulting autoconf will fail some of its tests.  Therefore, git is not
a strict bootstrap requirement, only a recommended one.  Meanwhile, if you
want to test the latest autoconf on a machine without git, and don't want
to fail tests related to version stamps, it may be easier to bootstrap on
a machine with git, run 'make dist', then copy the tarball over to the
machine for testing; it is a bug if we ever fail to support a working
distribution-style tarball that does not require the bootstrap tools.  I
haven't used git 1.4.4 for quite some time now, so let me know if we need
to bump the minimum recommended version.

- --
Don't work too hard, make some time for fun as well!

Eric Blake             address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkgEqnMACgkQ84KuGfSFAYCXkACgwox712XIX11hm0wvoOFTFKik
BWsAnA6QqMejcgvNO4UcUdFFmGPC0NY9
=0WIJ
-----END PGP SIGNATURE-----

>From c48d3a706fc252323d258fdea9382533293d4df5 Mon Sep 17 00:00:00 2001
From: Eric Blake <address@hidden>
Date: Tue, 15 Apr 2008 06:56:56 -0600
Subject: [PATCH] Mention more details about git usage in bootstrap.

Signed-off-by: Eric Blake <address@hidden>
---
 README-hacking |   20 ++++++++++++++++----
 1 files changed, 16 insertions(+), 4 deletions(-)

diff --git a/README-hacking b/README-hacking
index 0b8b0d9..f9b8873 100644
--- a/README-hacking
+++ b/README-hacking
@@ -11,7 +11,7 @@ maintainer-specific rules.
 We've opted to keep only the highest-level sources in the GIT repository.
 This eases our maintenance burden, (fewer merges etc.), but imposes more
 requirements on anyone wishing to build from the just-checked-out sources.
-For example, you have to use the latest stable versions of the maintainer
+For example, you have to use recent stable versions of the maintainer
 tools we depend upon, including:
 
 - Autoconf 2.60+ <http://www.gnu.org/software/autoconf/>
@@ -28,9 +28,24 @@ like "make dist-lzma" or "make distcheck":
 - Tar <http://www.gnu.org/software/tar/>
 - LZMA Utils 4.32+ <http://tukaani.org/lzma/>
 
+Although we try to keep the CVS mirror of the git repository usable,
+some of the tests in the testsuite will fail if git was not used to
+generate the version string.  Therefore, we recommend:
+
+- Git 1.4.4+ <http://git.or.cz/>
+
+You may find it useful to install the git-merge-changelog merge driver:
+http://git.sv.gnu.org/gitweb/?p=gnulib.git;a=blob;f=lib/git-merge-changelog.c
+
 Only building the initial full source tree will be a bit painful.
 Later, a plain `git pull && make' should be sufficient.
 
+If you want to test Autoconf on a machine without git, it may be
+easier to first bootstrap Autoconf on a different machine with git,
+run `make dist', and copy the tarball to the machine under test.  It
+should always be possible to create a self-contained tarball which
+does not rely on the bootstrap-only tools.
+
 * First GIT checkout
 
 You can get an anonymous copy of the source repository using any one
@@ -82,9 +97,6 @@ In most cases, a patch should include a test case, to ensure 
that
 regressions do not creep back in.  Remember to add documentation and a
 NEWS entry for anything that is visible to the user.
 
-You may find it useful to install the git-merge-changelog merge driver:
-http://git.sv.gnu.org/gitweb/?p=gnulib.git;a=blob;f=lib/git-merge-changelog.c
-
 If your change is significant (i.e., if it adds more than ~10 lines),
 then you'll have to have a copyright assignment on file with the FSF.
 Since that involves first an email exchange between you and the FSF,
-- 
1.5.5