Re: [bug-libsigsegv] [PATCH] Optimize gnulib checkout.

[Bruno Haible]

Hi Eric,

> @@ -47,7 +47,8 @@ if test $skip_gnulib = false; then
>      if test -d gnulib; then
>        (cd gnulib && git pull)
>      else
> -      git clone git://git.savannah.gnu.org/gnulib.git
> +      git clone ${GNULIB_SRCDIR:+--reference} $GNULIB_SRCDIR \
> +     git://git.savannah.gnu.org/gnulib.git
>      fi
>      # Now it should contain a gnulib-tool.
>      if test -f gnulib/gnulib-tool; then

Using "git clone --reference" is technically correct here, because when invoked
on a checkout which
  1. is not up-to-date w.r.t. HEAD
  2. has local commits
  3. has uncommitted modifications
the resulting checkout / clone
  0. contains no symlinks and no hardlinks,
  1. points to HEAD of the original repository,
  2. has ignored the local commits,
  3. has ignored the uncommitted modifications,

However, can you explain this part of "man git-clone" to me?

       --shared, -s
           When the repository to clone is on the local machine, instead of
           using hard links, automatically setup .git/objects/info/alternates
           to share the objects with the source repository. The resulting
           repository starts out without any object of its own.

           NOTE: this is a possibly dangerous operation; do not use it unless
           you understand what it does. If you clone your repository using
           this option and then delete branches (or use any other git command
           that makes any existing commit unreferenced) in the source
           repository, some objects may become unreferenced (or dangling).
           These objects may be removed by normal git operations (such as
           git-commit) which automatically call git gc --auto. (See git-
           gc(1).) If these objects are removed and were referenced by the
           cloned repository, then the cloned repository will become corrupt.

       --reference <repository>
           If the reference repository is on the local machine automatically
           setup .git/objects/info/alternates to obtain objects from the
           reference repository. Using an already existing repository as an
           alternate will require fewer objects to be copied from the
           repository being cloned, reducing network and local storage costs.

           NOTE: see NOTE to --shared option.

I can understand the NOTE for --shared. But what is the danger with
--reference? The cloned repository contains no symlinks, no hardlinks, and
no mention of the original referenced repository except in
.git/objects/info/alternates. So what can go wrong when using this option?

And should it use an environment variable GNULIB_SRCDIR?
  - For the purpose of libsigsegv alone, the use of the --reference option
    is only needed the first time a user runs autogen.sh. In the subsequent
    runs, a gnulib subdirectory is already present.
  - The variable GNULIB_SRCDIR is a misnomer, as it makes people think that
    the sources that it contains would matter. No, it's only the contents
    of the .git/objects subdirectory that matter, and in a semantically
    irrelevant way.
    As a reminder, gnulib's 'bootstrap' script only handles 2 out of 5
    reasonable use-cases, and the confusion about GNULIB_SRCDIR is part of
    the problem.
    <http://lists.gnu.org/archive/html/bug-gnulib/2010-03/msg00105.html>
    <http://lists.gnu.org/archive/html/bug-gnulib/2010-03/msg00165.html>
    
<http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=5990ad9e6ab590626a42764bf21dba6d7a05f237>

An environment variable makes sense, however, when a single user checks
out libsigsegv, libiconv, gettext, libunistring, and others. But since
GNULIB_SRCDIR is such a bad name, and even GNULIB_REFERENCE or GNULIB_CHECKOUT
would be ambiguous, we need a different name. What about GNULIB_ANYCHECKOUT
or GNULIB_DOWNLOADCACHE?

And then, of course, the documentation of autogen.sh (lines 8..11) needs to be
updated.

Bruno