* doc/gnulib-tool.texi (VCS Issues): Add details about using git submodules. * doc/.gitignore: Ignore another generated file.
Signed-off-by: Eric Blake <ebl...@redhat.com> --- > > Should I add more details on git commands > > used for creating an initial gnulib submodule, as well as ideas on how > > to update the submodule to newer gnulib commits? > That would be most welcome. Done. Here's what I'm pushing. ChangeLog | 7 +++++++ doc/.gitignore | 1 + doc/gnulib-tool.texi | 35 ++++++++++++++++++++++++++++++++++- 3 files changed, 42 insertions(+), 1 deletions(-) diff --git a/ChangeLog b/ChangeLog index 25a771a..115d59d 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,10 @@ +2010-03-08 Eric Blake <ebl...@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 <k...@gnu.org> * doc/gnulib-tool.texi (VCS Issues): Mention third option diff --git a/doc/.gitignore b/doc/.gitignore index 305af77..fbefd1b 100644 --- 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 --- a/doc/gnulib-tool.texi +++ b/doc/gnulib-tool.texi @@ -578,7 +578,7 @@ VCS Issues 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 @@ VCS Issues 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 -- 1.6.6.1