gnulib-tool.texi: mention possibility of git submodule

* doc/gnulib-tool.texi (VCS Issues): Add details about using git
submodules.
* doc/.gitignore: Ignore another generated file.

Signed-off-by: Eric Blake <eblake@redhat.com>

diff --git a/ChangeLog b/ChangeLog
index 25a771a9a7019b807c9e93cf18ec8bf0cf738e4f..115d59d0442ea71af82fb93b168f40c8442c3215 100644 (file)
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,10 @@
+2010-03-08  Eric Blake  <eblake@redhat.com>
+
+       gnulib-tool.texi: mention possibility of git submodule
+       * doc/gnulib-tool.texi (VCS Issues): Add details about using git
+       submodules.
+       * doc/.gitignore: Ignore another generated file.
+
 2010-03-08  Karl Berry  <karl@gnu.org>
 
        * doc/gnulib-tool.texi (VCS Issues): Mention third option

diff --git a/doc/.gitignore b/doc/.gitignore
index 305af77c0b88b8ff867574c70b6ea47af52a2776..fbefd1b8e7032fa0b487ed98fee695fa738040aa 100644 (file)
--- a/doc/.gitignore
+++ b/doc/.gitignore
@@ -14,4 +14,5 @@ gnulib.info-1
 gnulib.info-2
 gnulib.info-3
 gnulib.html
+gnulib.pdf
 updated-stamp

diff --git a/doc/gnulib-tool.texi b/doc/gnulib-tool.texi
index 1c396596b64bbba38e19e35e698b9d50f5f56102..02bb89a3955080955f0810e05830184daf0e34cd 100644 (file)
--- a/doc/gnulib-tool.texi
+++ b/doc/gnulib-tool.texi
@@ -578,7 +578,7 @@ generated from other source files, none of these files and directories
 are added into the VCS.  The only file that must be added to the VCS
 is @file{gnulib-cache.m4} in the M4 macros directory.  Also, the
 script for restoring files not in the VCS, customarily called
-@file{autogen.sh} or @file{bootstrap.sh}, will typically contain the
+@file{autogen.sh} or @file{bootstrap}, will typically contain the
 statement for restoring the omitted files:
 
 @smallexample
@@ -590,6 +590,39 @@ but it does not offer the possibility to change the way Gnulib is used.
 Also it does not report in the ChangeLogs the files that it had to add
 because they were missing.
 
+Gnulib includes the file @file{build-aux/bootstrap} to aid a developer
+in using this setup.  Furthermore, in projects that use git for
+version control, it is possible to use a git submodule containing the
+precise commit of the gnulib repository, so that each developer
+running @file{bootstrap} will get the same version of all
+gnulib-provided files.  The location of the submodule can be chosen to
+fit the package's needs; here's how to initially create the submodule
+in the directory @file{.gnulib}:
+
+@smallexample
+$ dir=.gnulib
+$ git submodule add -- git://git.sv.gnu.org/gnulib.git $dir
+$ git config alias.syncsub "submodule foreach git pull origin master"
+@end smallexample
+
+@noindent
+Thereafter, @file{bootstrap} can run this command to update the
+submodule to the recorded checkout level:
+
+@smallexample
+git submodule update --init $dir
+@end smallexample
+
+@noindent
+and a developer can use this sequence to update to a newer version of
+gnulib:
+
+@smallexample
+$ git syncsub
+$ git add $dir
+$ ./bootstrap
+@end smallexample
+
 @item
 Some projects take a ``middle road'': they do commit Gnulib source
 files as in the first approach, but they do not commit other derived