Erik Auerswald <auers...@unix-ag.uni-kl.de> writes: > This can be fixed by deleting the clone, creating a new one, and executing > the bootstrap script. But is there a nicer way for updating an exiting > git clone to also include the new gnulib module(s)?
BTW, here is how I deal with Gnulib stuff though. Since I am a committer there and build many packages to test gnulib-tool doing a clone each time would kill my data cap. So in my ~/.profile I have the following lines: # Try to reduce download size when installing GNU programs. if test -d "$HOME/.local/src/gnulib"; then GNULIB_SRCDIR="$HOME/.local/src/gnulib" export GNULIB_SRCDIR fi Setting that environment variable means running './bootstrap' does the same thing as './bootstrap --gnulib-srcdir="$HOME/.local/src/gnulib"'. This prevents ./bootstrap from performing a git clone. In the case of Inetutils, our bootstrap.conf has: GNULIB_REVISION=aacceb6eff58eba91290d930ea9b8275699057cf So ./boostrap simply goes to the local sources and checks out that commit before importing all the files. You might find it helpful to read ./bootstrap --help for more detail. There is also $GNULIB_REFDIR/--gnulib-refdir which does a 'git clone --reference'. I think it acompolishes the same thing but works better for projects using Gnulib as a submodule. Don't quote me on that though since that stuff gets too fancy for me. :) Collin
