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 25a771a..115d59d 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 305af77..fbefd1b 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 1c39659..02bb89a 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